**** BEGIN LOGGING AT Tue Jun 14 02:59:57 2011 Jun 14 09:25:15 hi all Jun 14 12:07:45 morning all Jun 14 12:17:33 hi RP__ Jun 14 13:34:40 hi Jun 14 14:19:10 hi holoturoide Jun 14 14:44:53 morning all Jun 14 15:22:31 zeddii: Hello ... Did you look at my use case of gathering the kernel version and storing it somewhere? Jun 14 15:25:21 it's still in my inbox, almost back down to it. I needed to get 3.0 and renames out of the way first. I was looking at the email just yesterday. My last reply is still the status, that it looks like something RP__ needs to consider. Can you resend the question to both of us to pop it up on the radar. Jun 14 15:29:07 jkridner, another big part of this work is the .config refactoring Jun 14 15:29:27 dvhart: hey there Jun 14 15:29:27 jkridner, and it seems there may be something there Jun 14 15:29:41 jefferai, heya Jun 14 15:30:00 dvhart: k. more to the refactoring than a simple merge? Jun 14 15:30:33 jkridner, yes, the hierarchical bsp branches also aggregate the .config fragments Jun 14 15:30:43 and we need to separate policy from board support Jun 14 15:30:56 ie which filesystems are supported is a yocto decision Jun 14 15:31:10 while the all the OMAP* options are something we should pull in directly Jun 14 15:31:20 dvhart: I still haven't booted yet (see my latest post on poky in regards to it), but IIRC sato is using X, not framebuffer, right? Jun 14 15:31:39 is this channel logged? Jun 14 15:31:44 jefferai, it use Xfbdev iirc Jun 14 15:31:55 jkridner, it is on my machine :) Jun 14 15:32:15 ah, ok -- so x input drivers should be able to be used (basically, I'm interested in getting a touchscreen to use with the beagleboard and have been looking around at possible options) Jun 14 15:32:28 denix: have you been looking at getting PSP and other meta-ti kernels to work with linux-yocto process? Jun 14 15:33:24 zeddii, see jefferai's comment re input drivers - I believe the answer is yes, but I think you mentioned touchscreen issues with the beagleboard in the past Jun 14 15:34:03 jkridner, but the .config is something I can work through on my own, I just wanted to get you the whole picture of the scope of the effort Jun 14 15:34:22 k Jun 14 15:34:40 jkridner, I also read on the forums that the uboot version can impact if the usb host controller works or not Jun 14 15:34:51 zeddii: I'm interested in e.g. http://www.mimomonitors.com/products/mimo-720-s ; theoretically all of the necessary software should exist (drivers in the kernel, evtouch xorg input driver, etc.) but I'm interested in knowing if anyone has tried this yet Jun 14 15:35:00 it'd be quite a useful thing to have :-) Jun 14 15:35:03 jkridner, so I'm currently using the angstrom u-boot.bin to eliminate that possibility Jun 14 15:36:37 jefferai. I know that the people around here looked into the mimo monitors, but I haven't seen one working myself. Jun 14 15:36:50 zeddii: do you know of any that are known to work? Jun 14 15:37:26 that was a subject of some debate about 6 months ago, I have a box with a couple of them here, I need to locate it. dvhart what were you using ? Jun 14 15:37:45 zeddii, I'm just using a simple HDMI display, no touchscreen Jun 14 15:37:52 aha. gotcha. Jun 14 15:38:15 I looked for my box o' kit last week, and it may have grown legs. I'll go look again shortly. Jun 14 15:38:58 thanks :-) Jun 14 15:39:25 Good Morning All ! Jun 14 15:48:38 Good morning. :) Jun 14 16:21:57 zeddii: ok; I will send it. Should I send it to where? oe-core? Jun 14 17:40:21 BTW I did a world build, and I'm comparing directory ownership throughout the system.. we've got somewhat of a mess.. :( we've got approx 316 directories with permissions that are not consistent between recipes Jun 14 17:40:36 a lot of them are things like 0755 in one, and 0775 in another package Jun 14 17:41:33 the directory ownership I'm working on should help fix SOME of this, but not all Jun 14 17:45:24 jkridner, fyi, a full build with 4.5.1 doesn't solve the issue for the C4 for me Jun 14 17:45:41 jkridner, I'll get on the board file comparison Jun 14 17:48:02 dvhart: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37/tree/arch/arm/mach-omap2/board-omap3beagle.c?h=yocto/standard/beagleboard ? Jun 14 17:48:36 no, one sec Jun 14 17:49:29 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/tree/arch/arm/mach-omap2/board-omap3beagle.c?h=dvhart/yocto/standard/beagleboard-ti-patched-yocto Jun 14 17:49:35 that is the one I'm currently building Jun 14 17:50:15 jkridner, I don't suppose you have a current version of the meta-ti kernel all patched up that you could post this file from? Jun 14 17:52:15 jkridner, I believe this is the important line for C4 ehci power up? Jun 14 17:52:18 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/tree/arch/arm/mach-omap2/board-omap3beagle.c?h=dvhart/yocto/standard/beagleboard-ti-patched-yocto#n498 Jun 14 17:54:16 http://dominion.thruhere.net/git/cgit.cgi/linux-omap/tree/arch/arm/mach-omap2/board-omap3beagle.c?h=beagle-2.6.39#n538 Jun 14 17:55:44 hrm, some differences there Jun 14 17:56:28 - usbhs_init(&usbhs_bdata); Jun 14 17:56:29 + usb_ehci_init(&ehci_pdata); Jun 14 17:56:36 that looks initeresting Jun 14 17:58:07 oh, jkridner that doesn't include the 200 patches in the meta-ti linux-omap recipe though does it? Jun 14 17:58:16 RP__: did you track down the build time spike you were seeing? Jun 14 18:00:33 it should include them for the 2.6.39 recipe, which works better than the 2.6.37 recipe. Jun 14 18:00:47 hrm Jun 14 18:04:21 I guess you are using http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-kernel/linux/linux-omap_2.6.37.bb ? Jun 14 18:04:29 yes Jun 14 18:04:38 as the linux-yocto kernel base is also 2.6.37 Jun 14 18:05:23 http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-kernel/linux/linux-omap_2.6.39.bb is what is actually getting miles on it. Jun 14 18:15:43 jkridner, so angstrom went from 2.6.32 to 2.6.39 - is that right? Jun 14 18:16:32 it did. there was a brief attempt at 2.6.37, but it stalled quickly. Jun 14 18:16:59 hrm Jun 14 18:16:59 lots of good stuff was accepted upstream between .37 and .39. Jun 14 18:17:17 our next release will be 3.0.0 or so Jun 14 18:17:36 and I hate to ditch everything I've done for the c4 ehci issue Jun 14 18:17:40 as the xM is working well Jun 14 18:17:41 isn't Linus dropping the 3rd digit? Jun 14 18:17:51 last I heard that was up in the air Jun 14 18:17:53 or are you planning to use a stable? Jun 14 18:17:57 k. Jun 14 18:18:01 we always use stable Jun 14 18:18:13 well, when will we be able to use meta-ti? Jun 14 18:18:24 jkridner, how do you mean? Jun 14 18:19:13 i mean is beagleboard always going to be different than how silicon vendors deliver bsps? Jun 14 18:34:15 BTW the patch and commit guidelines have been posted on OE wiki: http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines Jun 14 18:56:06 dvhart: yes, AFAIK 3.0.0-rcX will be 3.0 on the end Jun 14 19:55:08 ReaperOfSouls: No :/ Jun 14 20:04:10 So last week, we noticed a large spike in our builds. I didn't have a whole lot of time to debug, so I reverted to a previous merge point. The small debuggging I did it appeared to be spending a lot of time spinning on a futex. The builds we have running right now are 077657e50ad032c0fa876bf54e9802af2686e0fb with cherry picks of the fix for -s and -b breakages. I think the build we were using c3c2ad6f22e35b893a353d4c21d0e923e46ad07 Jun 14 20:05:19 I know Richard mentioned today that his builds went up by about 15 minutes and he wasn't sure why Jun 14 20:05:28 he'd not been able to figure it out Jun 14 20:05:28 The builds we were doing were the near current bitbake with relatively old content, which was using packaged statging which has a bit more locking. Jun 14 20:05:45 fray: Yeah thats why I was asking. :) Jun 14 20:07:27 ReaperOfSouls: Have you a good way to spot the excessive build time or not? Jun 14 20:07:43 Mine is just in overall build time which takes a couple of hours to test :( Jun 14 20:07:47 makes bisection hard Jun 14 20:08:31 ReaperOfSouls: I assume you're using the process server too? Jun 14 20:09:27 Unfortunately no not at the moment. I am trying to get the build stats stuff in to those builds, but they are still kinda crufty. Jun 14 20:10:16 We are just using the knotty interface atm. Jun 14 20:10:46 ReaperOfSouls: right, but its bitbake master which means the process server (vs. none or xmlrpc) Jun 14 20:10:59 Then yes. :) Jun 14 20:11:11 If that is the current default. Jun 14 20:14:12 * RP__ would swear the regression was more recent that the server changes :/ Jun 14 20:25:51 RP__: It very well could be something different. Since you were beating on it I figured I would toss that out there. Like I said it was a relitively new bitbake on a old bit of content so that might be related. Jun 14 20:26:09 RP__: Dumb question. Where is the selection made for which server? Jun 14 20:26:57 Ah nm see it. Jun 14 21:04:49 ReaperOfSouls: Its hardcoded at the moment but there are patches around to make it a commandline option Jun 14 21:42:27 * nitink is seeing this warning: NOTE: preferred version 2.14 of glibc not available (for item glibc) Jun 14 21:42:48 * nitink when PV = "2.14+git${SRCPV}" Jun 14 21:43:53 any trick to mute the warning ? Jun 14 23:38:43 nitink: PREFERRED_VERSION_glibc = "2.14+git%" ? Jun 15 02:34:03 pidge_: ping **** ENDING LOGGING AT Wed Jun 15 02:59:57 2011