=== heathkid|2 is now known as heathkid === Jack87 is now known as Jack87|Away [06:38] 'morning! [06:39] whats the current recommended way fo cross-building packages, especially kernel? [06:39] is xdeb still alive? [06:41] LetoThe2nd, xdeb is dead [06:42] LetoThe2nd, https://wiki.ubuntu.com/MultiarchCross [06:42] LetoThe2nd, also this http://gsoc.sitedethib.com/posts/apt-get_install_gcc-4.7-arm-linux-gnueabihf/ [06:42] 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] just set the cross-compiler prefix, and run config, and make with ARCH=arm [06:43] and install gcc-arm-linux-gnueabi[hf] [06:43] which is in ubuntu an emdebian [06:43] *and [06:43] scientes: does make-kpkg shonour the ARCH envirnoment variable? [06:45] make deb-pkg [06:45] please use that [06:46] 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] (if you have set up your .config right in the first place) [06:46] scientes: ok, will check that out. thanks! [06:48] the ubuntu kernel packages have configs in them to start you out if you need that [06:48] but really you need something for your board [06:49] 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] yeah you just set the cross compiler prefix variable [06:55] and you can even set arch in your .config [06:56] but i just run it with ARCH=arm make uImage [06:56] and gcc-arm-linux-gnueabihf in ubuntu or emdebian has all you need to cross-compile it [07:42] LetoThe2nd, http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/ [07:43] ogra_: ah, the usual suspects strike again [07:43] :) [07:43] ogra_: but does that apply to vanilla kernels also? [07:43] CROSS_COMPILE=arm-linux-gnueabi- make uImage [07:44] :) [07:44] gnah. [07:44] oh, might be gnueabihf nowadays [07:44] it is. [07:45] i mean, isn't there a compact way to cross-build vanilla kernels into a deb? [07:45] ah, i think they ship a way upstream but never used it [07:46] if its really vaniall mainline you wan, there is a kernel team PPA that has daily builds iirc [07:47] http://kernel.ubuntu.com/~kernel-ppa/mainline/ [07:47] ogra_: hard to use if you want to apply rt patches and spidev enablement... [07:47] that should be mainline just with the ubuntu packaging bits added [07:47] ah, k [07:48] CROSS_COMPILE=arm-linux-gnueabihf- make deb-pkg [07:49] try that one [07:49] i think thats the makefile target upstream ships for debs [07:49] yes, ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make deb-pkg [07:49] probably. [07:49] will let you know once i've copied everything over. [07:50] it wont be "proper" but at least it uses the package system [07:50] will lack "properness" in terms of? [07:50] so far i've just used make-kpkg on the target itself [07:51] dunno, but there must be a reason our kernel team takes the effort to do our own packaging ;) [07:52] possibly yes. [07:52] * ogra_ shakes his head about amazon spam ... [07:52] ogra_: pretty amazons? [07:53] based on my recent buyings they offer me "blah" ... [07:53] i just bought "blah" why would i be intrested to buy that again ? [07:53] probably from a different manufacturer than i just bought it from ... butu still, where is the logic in that === doko__ is now known as doko [09:51] <_Lucretia_> to build opengl, is there a deb with the headers in? [09:52] opengl ... on arm ?!? [09:53] <_Lucretia_> well, gles [09:53] there are mesa headers for it, yes [09:53] <_Lucretia_> there are mesa packages [09:53] <_Lucretia_> right, so just install that? [09:53] yes [09:53] <_Lucretia_> it won't overwrite any gl acceleration libs - not that i can find them [09:54] _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] _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] alf__, why wouldnt mesa work ? thats what we use for package builds afaik [09:56] 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] 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] else everything we build packaged for gles wouldnt work ;) [09:59] 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] _Lucretia_: Let me check... [10:03] <_Lucretia_> thanks [10:04] * _Lucretia_ doesn't have universe active in the repo [10:07] _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] https://launchpad.net/ubuntu/precise/+source/pvr-omap4/1.7.10.0.1.21-0ubuntu1 ... [10:09] <_Lucretia_> thanks [10:09] but if you used the PPA you should rather get the -dev package from there [10:09] i doubt the version matches whats in the ubuntu archive [10:10] (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] _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] ogra_: Do you know where ^^ is? Universe maybe? [10:15] <_Lucretia_> i can turn on universe [10:15] alf__, see the LP page ;) its in restricted [10:16] (which is enabled by default ... as well as universe and multiverse usually) [10:16] ogra_: but pvr-omap4 source doesn't seem to produce libgles2-sgx-omap4* [10:17] pvr-omap4-dev_1.7.10.0.1.21-0ubuntu1_armhf.deb [10:17] might be that rsalveti named it differently ? [10:18] <_Lucretia_> this is my sources http://pastebin.com/0b41Xi6T [10:18] I think that pvr-omap4* just contain the files, and libgles2/gles1/egl-sgx-* enable these using alternatives (or something like that) [10:20] _Lucretia_, looks fine [10:20] 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] ogra_: agreed [10:23] <_Lucretia_> ogra_: ok [10:24] <_Lucretia_> so does the alternatives work for selecting mesa/pvr? [10:24] _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] _Lucretia_: assuming you have libgles2-sgx-omap4 (but not -dev) [10:25] <_Lucretia_> libgles2-sgx-omap4 <- I don't have that [10:26] _Lucretia_: ok [10:26] <_Lucretia_> I have pvr-omap4-dev [10:28] <_Lucretia_> my version of ubu is precise [10:31] _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] _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] _Lucretia_: You can install all of gl/gles1/gles2 at the same time [10:37] _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] _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] 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] 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] 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] wow, i'm impressed the bot can handle the description [10:58] ... better than being compressed by the bot [10:58] heh [11:26] 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] is no_root_squash set ? (usual suspect) [12:29] ogra_: sure. its not for RFS anyways. [12:29] hmm [12:30] 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] do you have the nfs-common stuff installed ? [12:31] yes. [12:32] stgraber, any ideas ? ^^^ [12:32] * ogra_ hasnt actually used nfs in years [12:32] does nfs-mounting produce any logging somewhere? [12:32] syslog i would guess [12:33] 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] nah, better debug it [12:34] lsmod shows nfs i suppose (and /proc/filesystems) [12:36] check. /proc/filesystems{nfs,nfs4,nfsd} are marked with nodev, though [12:36] are you using v4 actually ? [12:36] * ogra_ isnt sure if you dont need nfs4-acl-tools then [12:37] not actively decided for v4 [12:45] the exports declaration is also classically v3 [12:46] weird [12:46] /srv/panda192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check) [12:46] yeah [12:46] hm. IIRC i've had a lockout earlier when using another NFS mount [12:46] lockup [12:47] tried async ? [12:47] just done. no effect. [12:48] pinging the ip of the server works ? [12:48] yep. [12:48] (and i assume the spaces in your fstab line above were just eaten by the paste) [12:49] err /etc/exports line [12:49] ogra_: correct assumptions. irssi ate my tabs. [12:50] well, smells like a bug but without any data in dmesg or syslog its hard to nail down [12:51] dmesg is dead silent [12:51] no mount errors in syslog ? [12:53] also dead silent [12:53] very weird [12:53] i think i'll start over with the backupped image. [12:53] if it still appears then, it really is a hard bug. [12:53] well, we need at least some datapoints [12:58] hard to find. [13:07] 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] which kernel module can enable OTG as 'host mode' ? so I can set it to load first in 'uInitrd' [13:10] stgraber: only talking about post-boot, its a share i want to use for data transfer [13:25] 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] ogra_: thanks [13:38] it seems ubuntu has poor support for these devices :( [13:41] feel free to help out with patches :) [13:42] I mean they release those 'pre-build' images for us to download, but it's unable to run [13:42] ?? [13:42] they get tested pretty heavily before being released [13:43] 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] s/we/why/ [13:43] 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] connect to the normal USB? [13:44] as i said, feel free to file a bug and submit a patch that fixes it [13:44] the Blaze has only a OTG to connect USB devices [13:44] a blaze isnt a pandaboard [13:45] i knew [13:45] if you have a blaze you should also have a contract with TI ... they provide ubuntu images adjusted for blazes [13:46] so it's a proprietary developed image ? [13:46] no, its the same image with adjustments for the blaze [13:47] i.e. a different kernel that has OTG enabled i suppose [13:47] ask your TI representative ;) [13:47] this mean I have to find my contract, then ask TI for the image to download ? [13:47] i guess so [13:48] ok, thanks [13:48] the panda image works on the blaze but is definitely not optimized in any way for it [13:49] I thought I can find a kernel module and put in 'uInitrd' to force it load first during bootup and enable OTG. [13:50] well, apparently not witzh the pandaboard kernel [13:56] rsalveti: Hi! Are there any libgl*-sgx-omap4 packages for precise armhf (not linaro)? I can only find pvr-omap4* [14:51] ogra_: after reverting to backup, mount works fine. hmh. === morphis|away is now known as morphis === 1JTAAA5GX is now known as jkridner [15:19] LetoThe2nd, cosmic rays [15:22] ogra_: either that, or lack of metal mp3s on the nfs share. [15:23] hah === Quintasan_ is now known as Quintasan [16:55] 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] Sata, 1Gb ethernet, 2G mem, 802.11n come to mind.? [16:59] Bazillions of gigs of RAM! [16:59] But you already have my feedback. ;) [17:00] Sounds like someone wants to rebuild OOo. [17:00] 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] please add to the thread if you have time [17:03] 2G mem ? [17:03] * ogra_ just wants DRAM sockets ! [17:03] with no limits ! [17:06] prpplague: Responded. [17:06] infinity: thanks [17:09] alf__: the pvr-omap4 replaces the others [17:09] alf__: because it uses alternatives [17:10] ogra_: LetoThe2nd ^ [17:10] so we don't have the libgl* packages anymore [17:10] rsalveti: your feedback would greatly appreciated as well [17:11] prpplague: oh, cool, will check [17:11] rsalveti, thats what i thought, thanks for confirming [17:37] prpplague: any ETA for this board? [17:38] * prpplague can't make any statements on that [17:38] ppisati: but any info you post on the list would be extremely helpfu; [17:38] helpful [17:38] brb need food [17:38] prpplague: i don't have any info, i want info :) [17:38] * ogra_ is in line with maens on the rs232 :) [17:39] prpplague: ram sockets, sats and pci-e [17:39] prpplague: that would be perfect [17:39] 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] oh, and no microSD ... [17:40] i hate using adapters [18:00] ogra_: i did not understand your statement about usb powering [18:00] prpplague, you didnt read my blogpost then :) [18:00] ogra_: url? [18:00] http://ograblog.wordpress.com/2012/08/06/the-bamboo-feeder-automating-continuous-arm-image-tests/ [18:01] 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] it made a lot of sense on the beagle ... but the more power you require the less useful it is [18:04] ogra_: yes that is why we recommend the dual usb cable, similar to whats used on external HD's and cdroms [18:04] ogra_: but i am not understanding your "power cycle" issue [18:04] 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] if i power off the PSU, the boards stay on [18:05] pulling their power from mini usb [18:05] ogra_: they shouldn't be as long as you have the barrel jack inserted [18:05] well, they are [18:06] ogra_: even when the barrel jack is inserted? [18:06] well, the web controlled power strip has no robot arm attached, so yes :) [18:06] 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] ogra_: 4430 or 4460? [18:07] all of them [18:07] from EA1 to ES B1 [18:07] i havent found a model that would power off in this setup [18:07] 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] there is nothing to understand, use the std PSU and a usb->miniUSB cable [18:08] ogra_: i wish you had checked with me sooner on this [18:08] ogra_: yea thats how we test it [18:08] prpplague, i only discovered it during this project last weeks monday [18:09] but i can always reproduce, even with my pandas at home [18:09] as long as mini usb is attached they recieve power [18:09] no matter if i pull the barrel connector or the wall plug [18:09] anyway, i worked around i, works fine now :) [18:10] s/i/it/ [18:10] ogra_: yea that bothers me, because we specifically test for that [18:10] 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] ogra_: i just tested two boards here, neither show that issue [18:10] funny [18:11] ogra_: the board is specifically designed to not allow that to happen [18:11] ogra_: no mods done to your boards? [18:11] well, what should i say [18:12] nope, they came freshly out of the boxes or out of bubblewrap .... [18:12] ogra_: interesting [18:12] we have several different models there [18:12] ogra_: i'll grab some off the assembly line for testing [18:12] i kept the EA1 though [18:13] (doesnt make sense to test on such old HW) [18:13] now EA1 boards might have an issue [18:14] well, thats why i kept it out of the loop ;) [18:14] the others are all ES [18:14] different versions though (dont ask me which, i remember an A1 and a B1, all that are in now have black PCBs) [18:15] ogra_: i'll rerun a bunch of tests to see if can replicate the issue [18:15] it works fine as it is now and i wont be able to tear it apart anymore [18:15] (beond me being 4000 miles away from it) [18:15] but i need to know why you were having that problem [18:16] i'll try to replicate it her tomorrow with the boards i brought back [18:20] ogra_: interesting [18:21] ogra_: i just tested A1-A4 of pandaboard [18:21] ogra_: all work properly [18:21] and let me guess, you dont get the issue [18:21] fun [18:21] ogra_: i am wondering if all of yours were made by either circuitco or svtronics [18:22] how would i tell ? [18:22] (apart from not having the boxes anymore or any physical access) [18:23] as i said, i can test tomorrow ... now GF calls and she will slay me if dinner gets cold ... [18:23] ogra_: no worries [18:23] ogra_: i suspect there has been an incorrect placement of a resistor on your boards [18:23] oh, i'm not worried, the setup works fine :) [18:23] and i really enjoyed doing the hw hack ... [18:24] nobody was injured, result was good ;) [18:26] ogra_: hehe, yea, just worries me [18:26] ogra_: i'll dig around to find out if we have a BoM issue [19:40] 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] And I have several different rev boards, from EA1 to ES B1. [19:55] 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] that's my current pain point with usb-to-serial controllers as console server [19:59] 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] I didin't use the mini-usb. OTG was too unstable between kernel rev's. [20:00] I used mini-usb as one of the two boot methods, mainly to pull a preinstalled or netboot image to SD. [20:02] 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] 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] seems quite doable, just never got high enough on the todo list [20:11] ojn: It's not even remotely doable with most USB->Serial dongles, actually. [20:11] ojn: Most have no unique identifier. [20:11] (Unless you intentionally buy several different brands) [20:12] just look at all the insanity in gpsd cause gps devices actually look like serial dongles [20:12] 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] infinity, hmm, i was pretty sure the ones I looked at had serial numbers. Grmbl. [20:13] I thought I escaped modems 20 years ago. [20:13] Apparently not. [20:13] ojn: None of mine do. [20:14] ojn: And GrueMaster's squid-like one with several dongles had no way to uniquely identify the tentacles. [20:14] awesome [20:15] It makes perfect sense, really. [20:15] 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] The tiny subset of their customers that might care (ie: us) really aren't enough to worry about. [20:16] s/marging/margin/ [20:16] Yea, my "squid" cable was esentially a hub in the center with 4 individual serial chips (pl2303 iirc) on the ends. [20:17] If they had serial numbers in the usb device info, udev would be a no-brainer. [20:18] 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] VM + usb passthrough? :) [20:19] stgraber: ??? [20:20] Straight Windows. Sadly, I have had to revert to running Linux in a VM. Only way to do decent coding. [20:20] (and ensure my boss doesn't powercycle my Linux dev system...again. [20:22] 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] then no more serial driver problem [20:22] (though probably a whole lot of other problems) [20:23] The Windows software has a slew of incompatibilities with Wine. Doesn't even like to run in a Windows VM (I tried). [20:23] The different programs I have to deal with are...interesting at best. [20:23] stgraber: That's just disgusting. :P === jkridner_ is now known as jkridner [20:24] 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] Meh. I've done worse things (like running a dos envirounment in a vm under an emulator. [20:24] I suspect said proper driver might already exist, and the "driver disks" are nothing more than .inf files. [20:25] True. But without that inf file, you're hosed. [20:25] Surely, the Internets can provide. [20:25] And since there are no markings on said cable, no way to look up the vendor. [20:25] Or you can yank the USB IDs from Linux and write an INF file. :P [20:26] I looked, but all I could find were malware sites with "We can identify what drivers you need" crapware. [20:26] Still need the dll for the actual serial chip. MOStech, iirc. [20:26] In the end, I threw the cable in the trash and went across the street to buy two new Trendnet cables. [20:27] At my salary rate, it was cheaper to get new cables.