**** BEGIN LOGGING AT Thu Jan 27 02:59:57 2011 Jan 27 09:58:37 did someone had keyboard-configuration hang on postinst on panda? Jan 27 10:01:14 sveinse: have a moment to discuss bug 683832? Jan 27 10:01:16 Launchpad bug 683832 in gcc-4.5-armel-cross "gcc fails to cross compile Qt" [Undecided,Confirmed] https://launchpad.net/bugs/683832 Jan 27 10:02:44 Yes, I do Jan 27 10:03:44 sveinse: did you tried to compile in ARM mode? Jan 27 10:03:52 sveinse: Thumb2 is default Jan 27 10:04:35 hrw, Yes, that works. However I'm if it has any performance impact Jan 27 10:05:16 sveinse: for Thumb2 mode you need to check ubuntu qt patches Jan 27 10:05:36 there were some for it iirc Jan 27 10:07:02 hrw, console-setup being broken is a known issue and not arm specific Jan 27 10:07:04 as this bug is a bug in Qt not in gcc Jan 27 10:07:25 ogra: ok, but it hangs only on arm for me so thats why I asked here Jan 27 10:07:25 no idea whats the workarouns Jan 27 10:07:49 ogra: rm /var/lib/dpkg/info/keyboard-configuration.postinst ;d Jan 27 10:07:54 if you upgrade to natty you get about 20 requests to configure your kbd Jan 27 10:07:55 hrw, Yes. Qt does have some fixes for the thumb2 issue which I have also tried Jan 27 10:08:18 ogra: I am on natty Jan 27 10:08:30 However it fails during early compilation. Let me see if I can find the error. Jan 27 10:08:33 and yes, console-setup is insane Jan 27 10:08:59 anyway... console-setup does not even lists my keyboards ;S Jan 27 10:09:06 hrw, when do you run the keyboard configuration then if you are on natty ? Jan 27 10:09:16 hrw, The reason I'm mentioning this is I'm suspecting some difference between CSL and Linaro/ubuntu gcc Jan 27 10:09:25 the issue is that some value is missing in /etc/default/console-setup Jan 27 10:09:36 ogra: during "apt-get upgrade" Jan 27 10:09:44 ah, k Jan 27 10:10:03 sveinse: I think that csl defaults to -marm, ubuntu defaults to -mthumb Jan 27 10:10:04 well, thats the same i get when upgrading from maverick then Jan 27 10:11:24 hrw, i think its CHARMAP or CODESET being empty that causes this Jan 27 10:11:25 hrw, but for your inital question -marm fixed the compilation as such Jan 27 10:17:25 ok Jan 27 10:17:43 hrw, however my qt compilation relies on sysroot... I haven't figured out how to cross compile without it yet (nor has I investigated how to, so its on me) Jan 27 10:18:51 sveinse: "xapt install lib1 lib2 lib3" + configure + make Jan 27 10:19:53 hrw, lib1 lib2 lib3 being the libxxx-dev build-depends to the software you're building, right? Jan 27 10:21:11 yes Jan 27 10:21:19 elegant! Jan 27 10:21:32 works under natty, no idea about maverick Jan 27 10:26:37 hrw, why doesnt xapt-get build-dep work ? Jan 27 10:26:51 no idea? Jan 27 10:27:03 i.e. why doesnt it just stick to apt syntax Jan 27 10:29:30 good question Jan 27 10:29:54 probably fast written tool while waiting for multiarch Jan 27 10:33:50 heh Jan 27 10:34:41 hrw: hang > that sounds like very very slow perl, I had that a while ago; maybe it's something else though Jan 27 10:35:49 lool: I just removed postinstall scripts Jan 27 10:36:35 lool: a4tech keyboard which I use do not require extra config. and is not listed in console-setup list anyway Jan 27 11:18:11 hrw, if I check out qt on the master branch (where qt has fixed the thumb2 issue), the compilation fails in the compilation of the first file: Jan 27 11:18:22 {standard input}: Assembler messages: Jan 27 11:18:24 {standard input}:527: Error: thumb conditional instruction should be in IT block -- `strexeq r2,r5,[r6]' Jan 27 11:18:25 {standard input}:528: Error: thumb conditional instruction should be in IT block -- `teqeq r2,#1' Jan 27 11:19:02 Now, I dont know if this is related to GCC or if its a qt issue. Is this familiar? Jan 27 11:19:32 familiar Jan 27 11:19:33 moment Jan 27 11:19:57 check bug 675347 Jan 27 11:19:58 Launchpad bug 675347 in gcc-linaro "volatile int causes inline assembly build failure" [Medium,In progress] https://launchpad.net/bugs/675347 Jan 27 11:20:54 no, it is rather bug 682742 Jan 27 11:20:55 Launchpad bug 682742 in thunderbird "thunderbird doesn't build on armel in natty (Error: thumb conditional instruction should be in IT block)" [High,Fix released] https://launchpad.net/bugs/682742 Jan 27 11:21:31 hm.. not this too Jan 27 11:21:37 there was a bug about it... Jan 27 11:21:38 :D Jan 27 11:22:35 bug 490371 Jan 27 11:22:36 Launchpad bug 490371 in qt4-x11 "Atomic operations not safe for ARMv7,Thumb-2 and multicore" [Medium,In progress] https://launchpad.net/bugs/490371 Jan 27 11:23:17 also bug 673085 Jan 27 11:23:18 Launchpad bug 673085 in qt4-x11 "Qt/KDE fails to build on ARM without implicit-it=thumb" [High,Fix released] https://launchpad.net/bugs/673085 Jan 27 11:25:07 What is the difference of armv6 and armv7? Because the qt fix in 490371 is agains armv6 it seems Jan 27 11:25:10 there is a new QT coming this week i was told Jan 27 11:25:20 that might fix some of these issues Jan 27 11:25:36 Could check the beta, unless it's a fix since then Jan 27 11:25:43 ogra, we're using git, not the official snapshots/releases Jan 27 11:26:22 and the armel compilation issue is still present in the head of their branches Jan 27 11:26:59 sveinse: there were no optimizations for armv7 in Qt so armv6 ones are used or sth like that Jan 27 11:27:39 I'm a little surprised that qt doesn't fix this, armel build for qt must surely be focus area for nokia Jan 27 11:30:01 erm, indeed, our package sets -march=armv6 Jan 27 11:35:30 I think I shall check out the qt source package to see if there are any other relevant qt patches for armel Jan 27 11:35:55 i think there are a bunch Jan 27 11:36:09 probably also check other projects for their patches Jan 27 11:37:35 yeah, checking OE usually makes sense for arm patches Jan 27 11:40:13 ogra: and vice versa ;D Jan 27 11:40:30 ogra: OE has Debian, Ubuntu, Gentoo, Fedora patches Jan 27 11:40:55 well, i wouldnt really care for the armv5 patches of debian or fedora Jan 27 11:51:39 Actually, a lot of the armv5 patches *also* help with armv7 (which is part of why we have all of the Debian ones in Ubuntu) Jan 27 12:34:42 hrw, Do I understand that I should be the one to close bug 683832 ? Jan 27 12:34:43 Launchpad bug 683832 in gcc-4.5-armel-cross "gcc fails to cross compile Qt" [Undecided,Confirmed] https://launchpad.net/bugs/683832 Jan 27 12:36:58 sveinse: I prefer you to be one, or I can mark it as invalid Jan 27 12:41:20 hrw, done Jan 27 12:41:51 thx Jan 27 14:33:58 bug 684148 Jan 27 14:33:59 ogra: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/684148) Jan 27 14:49:29 LP #684148 Jan 27 14:49:30 Launchpad bug 684148 in unity-2d "[i18n] integrate gettext and use translations from Unity" [High,Triaged] https://launchpad.net/bugs/684148 Jan 27 14:49:33 Ah Jan 27 15:04:58 ogra: did you move the image script for omap4 to get the new x-loader from the new package? Jan 27 15:05:08 ogra: then we can request the removal of x-loader-omap4 Jan 27 15:06:07 rsalveti, can you check if it actually ends up on the image ? Jan 27 15:06:17 (yes, i did change the scripts) Jan 27 15:06:35 ogra: sure, just wanted to ask you first, as I know you changed for omap3 Jan 27 15:06:37 but don't know for omap4 Jan 27 15:06:45 will check the logs Jan 27 15:07:19 i changed both at the same time Jan 27 15:08:04 cool, so we should be fine Jan 27 15:30:22 hi guys i know you guys you did a lot of work in lucid to get arm working on likewise-open do you guys want to take another crack at it? Jan 27 15:30:42 ogra, i've got some new kernels previews you might like to test: http://people.canonical.com/~apw/misc/arm/ Jan 27 15:31:00 apw: why preview? Jan 27 15:31:07 what is special about this kernel? Jan 27 15:31:32 preview as in the arm kernels take days to build in the archive so won't be in there for at least another 24 hours Jan 27 15:31:42 so these are hand built for earlier access Jan 27 15:31:47 apw: oh, ok, cool Jan 27 15:31:51 will give it a try now Jan 27 15:43:32 weee, kernel panic while installing new deb hehe Jan 27 15:43:47 * rsalveti is trying again Jan 27 15:57:18 ogra: ac100 has sata internally used? Jan 27 15:58:37 no Jan 27 15:58:57 ogra: emmc storage? Jan 27 15:59:02 yep Jan 27 16:00:08 apw: eeek, not good Jan 27 16:00:18 thx ogra Jan 27 16:00:25 rsalveti, s'up Jan 27 16:00:26 apw: http://paste.ubuntu.com/559064/ Jan 27 16:00:43 warning but later on failed to start omapfb Jan 27 16:00:45 so, no display Jan 27 16:01:10 rsalveti, not sure if the warning matters per-see Jan 27 16:01:18 not having a framebuffer looks more annoying Jan 27 16:01:41 yeah, don't know if they are related atm, need to properly check the code Jan 27 16:02:02 rsalveti, yeah Jan 27 16:02:42 well, at least some fun debugging time for later today Jan 27 16:05:06 rsalveti, yeah :) we have a couple of days (well two i guess) before we freeze for A2 Jan 27 16:06:50 apw: ok, ping you back if I get any other news about it Jan 27 16:07:00 Hey all. Jan 27 16:07:34 rsalveti, thanks ... i note there is exactly one commit between v2.6.37 and the tip for omapfb Jan 27 16:07:46 Going from ubuntu netbook version to ubuntu desktop is just a matter of removing ubuntu-netbook package and installing ubuntu-desktop, right? Jan 27 16:08:18 apw: cool, just checkout out the git tree Jan 27 16:11:38 rsalveti, ok that warn_on is telling you you have an erratum Jan 27 16:11:43 if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) { Jan 27 16:12:17 rsalveti, any idea what graphics driver one should have? Jan 27 16:12:44 Wow. Firefox is using 172% of cpu on omap4, reporting an oem-config crash bug. Jan 27 16:18:09 rsalveti, do you have the whole of the dmesg Jan 27 16:18:29 apw: not yet, checking the code atm Jan 27 16:18:32 apw: sure, 1 sec Jan 27 16:22:03 apw: http://paste.ubuntu.com/559074/ Jan 27 16:22:41 [ 0.147460] Unable to get DVI reset GPIO Jan 27 16:23:38 [ 4.675109] regulator_init_complete: VPLL2: incomplete constraints, leaving on Jan 27 16:23:38 [ 4.682983] regulator_init_complete: VDAC: incomplete constraints, leaving on Jan 27 16:25:04 commit f8362d215549c66066f78e67c033dd370ae50322 Jan 27 16:25:04 Author: Koen Kooi Jan 27 16:25:04 Date: Tue Jan 11 17:13:36 2011 +0000 Jan 27 16:25:04 omap3: beaglexm: fix DVI reset GPIO Jan 27 16:25:06 rsalveti, th Jan 27 16:25:16 rsalveti, though we _have_ that in the kerenls you are running Jan 27 16:25:49 rsalveti, is this an XM or regular Jan 27 16:26:05 XM Jan 27 16:29:37 rsalveti, i idly wonder if yours is on the other gpio number Jan 27 16:31:32 rsalveti, the v2.6.37 based kernel worked on your xM didn't it? Jan 27 16:31:50 rsalveti, diffing to there there is no mention of the 129 gpio in the code before Jan 27 16:32:20 apw: 37 worked fine Jan 27 16:32:46 rsalveti, also i see that things like cpus and swap coming up in the dmesg, were you able to login to the machine remotely? i suspect other than the display it came up Jan 27 16:33:03 apw: yup, login works fine Jan 27 16:33:24 rsalveti, i think i might suggest that you try as a first stab making this bit always use 170 Jan 27 16:33:27 + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) Jan 27 16:33:27 + beagle_dvi_device.reset_gpio = 129; Jan 27 16:33:27 + else Jan 27 16:33:27 + beagle_dvi_device.reset_gpio = 170; Jan 27 16:33:36 as i think in 27 it always used 170 for all beagles Jan 27 16:34:16 static struct omap_dss_device beagle_dvi_device = { Jan 27 16:34:16 .type = OMAP_DISPLAY_TYPE_DPI, Jan 27 16:34:17 [...] Jan 27 16:34:21 - .reset_gpio = 170, Jan 27 16:34:28 was the old .27 code Jan 27 16:36:40 apw: at maverick we have this change, but differently Jan 27 16:36:46 but also using 129 for xm Jan 27 16:36:50 so it should be fine Jan 27 16:37:12 but weird that it worked fine for 37 Jan 27 16:37:21 if it was only using 170 Jan 27 16:37:36 rsalveti, welll not necessarily Jan 27 16:38:01 static int beagle_enable_dvi(struct omap_dss_device *dssdev) Jan 27 16:38:01 { Jan 27 16:38:01 if (gpio_is_valid(dssdev->reset_gpio)) Jan 27 16:38:01 gpio_set_value(dssdev->reset_gpio, 1); Jan 27 16:38:03 return 0; Jan 27 16:38:08 as the platform init does that Jan 27 16:38:38 on maverick the reset_gpio was struct was set as 170 Jan 27 16:38:46 but then we had a check at beagle_display_init Jan 27 16:39:06 then then set it correctly if it's a xm Jan 27 16:39:22 *that then Jan 27 16:39:37 but then that other check may occur in time before it or something Jan 27 16:39:42 so 37 probably had something similar Jan 27 16:40:22 using the diff from v2.6.37 and the tip of natty 129 does not appear with a - Jan 27 16:40:33 ie if it was there its still there Jan 27 16:43:32 rsalveti, we might also consider putting the failed gpio pin number in the error on failure Jan 27 16:43:39 might help know if its an init ordering issue Jan 27 16:45:39 rsalveti, hrm how much did you miss i wonder Jan 27 16:45:58 let me check the logs from bip Jan 27 16:46:14 rebooting my host pc, got dead for some unknown reason Jan 27 16:46:15 natty Jan 27 16:46:21 hrm Jan 27 16:46:39 still 37 :-) Jan 27 16:46:46 but with btrfs Jan 27 16:46:48 :) good Jan 27 16:46:53 :( bad Jan 27 16:47:35 yeah :-( Jan 27 16:48:30 rsalveti_, so any oppinion as to what debug to shove in, and will you do it, or do you need me to make kernels Jan 27 16:48:57 don't worry, I can check this here Jan 27 16:49:01 and easily cross build the kernel Jan 27 16:49:20 ok cool ... i guess we are at 'have h/w will debug stage' so i'll get out your hair Jan 27 16:49:35 ok, ping you back with more results later Jan 27 16:49:38 thanks anyway Jan 27 16:49:52 where do you have his hair ? in a drawer ? Jan 27 16:50:26 * ogra imagines apw with a rsalveti wig Jan 27 16:50:30 rsalveti, :) thanks Jan 27 16:50:33 ogra, with mine yep :) Jan 27 16:50:43 *g* Jan 27 16:52:17 rsalveti, do keep me in the loop as i will need to upload pretty soon for A2 as you know and i have some bits for aufs pending which i would batch up with yours :) Jan 27 16:52:28 apw: sure, np Jan 27 16:59:12 Hey, maybe we can use these as buildd's. Quad core Cortex A9, portable (small), what's not to like? http://games.slashdot.org/story/11/01/27/1432205/Sony-Reveals-the-Next-Generation-Portable-Console Jan 27 17:20:57 GrueMaster: hehe Jan 27 17:21:14 GrueMaster: i suspect it isn't going to be quad core Jan 27 17:21:24 GrueMaster: first versions probably with just be dual core Jan 27 17:22:26 I just saw the article and the mention of quad core Cortex-A9. I have no detailed specs yet, but haven't looked either. Jan 27 17:49:18 hey all, I'm trying to get the 10.04-server-armel+omap image working with qemu (emulating a beagleboard). I have it booting to the install script (where you select a language) but the keyboard doesn't work. I ran a debian image just fine with the same emulator, so I'm starting to think it's not the qemu build.Anyone experience this before? Jan 27 18:04:26 * apw wonders how rsalveti is getting on :) Jan 27 18:07:16 apw: waiting a build to finish, to properly check what's happening, my host seems quite unstable atm :-( Jan 27 18:07:21 had to reboot 2 times already Jan 27 18:08:04 apw: how is the 38 testing going? Jan 27 18:08:10 * rsalveti thinking about changing to 38 Jan 27 18:08:25 but heard people were facing lots of issues with it Jan 27 18:08:33 rsalveti, ahh how long does it takeing Jan 27 18:08:53 my machines here are running .38 based kernels, previews like the arm ones, but i'd not say i was stressing them Jan 27 18:09:27 apw: hm, what are you running at your desktop? Jan 27 18:09:35 38? Jan 27 18:10:00 this machine is back furhter than that Jan 27 18:10:12 my other smaller boxses are on the preview though Jan 27 18:10:23 running unity, when it works Jan 27 18:10:35 hehehe Jan 27 18:10:48 mine is very broken Jan 27 18:11:15 using classic desktop atm, with metacity instead of compiz 2d Jan 27 18:11:53 so this machine is all uptodate, including the upcoming kernel Jan 27 18:11:57 and its holding together mostly, well as long as you remeber to right click to get the menus working Jan 27 18:12:13 hehe, cool, maybe will update mine later on Jan 27 18:12:15 today Jan 27 18:12:31 but i've not got the guts to put it on my bigger machine as i am not yet ready for the paradigm shift Jan 27 18:13:23 just about to do an update on a desktop Jan 27 18:14:59 something to check later is why it's powering DVI down using 170 as a hardcoded value at omap3_beagle_init Jan 27 18:15:25 while when starting up it checks if it's running xm or not, and select the proper gpio pin Jan 27 18:16:11 don't know what is connected to 170 at xm Jan 27 18:16:16 need to check the hw docs Jan 27 18:37:53 rsalveti, this bit you mean: Jan 27 18:37:57 omap_mux_init_gpio(170, OMAP_PIN_INPUT); Jan 27 18:37:57 gpio_request(170, "DVI_nPD"); Jan 27 18:37:57 /* REVISIT leave DVI powered down until it's needed ... */ Jan 27 18:37:57 gpio_direction_output(170, true); Jan 27 18:38:10 looks like it should be using the reset_gpio as well indeed Jan 27 18:38:40 yup Jan 27 18:38:57 maybe... hard to tell it does use different descriptions Jan 27 18:39:09 as if 170 is power and 129 is reset on xm, but both on !xm Jan 27 18:39:13 all depends on semantics i guess Jan 27 18:39:27 the docs sounds like ones freind here for sure Jan 27 18:43:35 rsalveti, the below sounds bad: Jan 27 18:43:48 "Passing invalid GPIO numbers to gpio_request() will fail, as will requesting Jan 27 18:43:48 GPIOs that have already been claimed with that call." Jan 27 18:44:06 as far as i can tell for !xm we would request 170 twice and violate that Jan 27 18:44:14 which would lead to that error ... Jan 27 18:44:24 hm, makes sense Jan 27 18:46:04 on maverick this was remove with commit 8c3818913431c5ae62a7e56a38d38c4ca81ee4a2 Jan 27 18:46:07 let me check 37 Jan 27 18:46:49 rsalveti, oh yeah its removed ... hrm Jan 27 18:47:35 * rsalveti is still waiting his build to finish Jan 27 18:47:54 rsalveti, how long do they take ? Jan 27 18:48:12 this is the first one, then I can just make what changed Jan 27 18:48:18 but 30 min probably Jan 27 18:48:35 apw: if it's faster for you, can you try removing that out and build it again? Jan 27 18:48:56 rsalveti, about the same once i've pushed it so you can get to it Jan 27 18:49:17 omap_mux_init_gpio(170, OMAP_PIN_INPUT); Jan 27 18:49:17 gpio_request(170, "DVI_nPD"); Jan 27 18:49:17 /* REVISIT leave DVI powered down until it's needed ... */ Jan 27 18:49:17 gpio_direction_output(170, true); Jan 27 18:49:22 seems it was in there for .37 Jan 27 18:49:34 which is perplexing Jan 27 18:49:40 hm, not from one I'm seeing here Jan 27 18:49:52 from Ubuntu-2.6.37-9.22 Jan 27 18:49:55 let me check again Jan 27 18:50:25 git show Ubuntu-2.6.37-9.22:arch/arm/mach-omap2/board-omap3beagle.c Jan 27 18:50:27 sounds fine Jan 27 18:50:29 yeah Jan 27 18:50:55 yep clearly new... Jan 27 18:51:01 shall i build without that in parallel ? Jan 27 18:51:12 apw: sure Jan 27 18:54:00 rsalveti, i can see how that got lost, as we dropped all the omap stuff for XM as it was coming down in spades from upstream ... clearly not all of it Jan 27 18:54:29 apw: yup, the same patch that changes to use 129 is the one who removes this piece Jan 27 18:54:39 and you got a conflict and probably just removed the patch Jan 27 18:55:41 yep thats what i would have done, there is clearly stuff in there saying "added support for Xm" so it would be a simple choice to drop Jan 27 18:55:56 rsalveti, heres hoping thats the main issue Jan 27 18:56:28 if i had been diffing to a sensible place for .37 i'd have noticed that too ... silly me Jan 27 19:05:33 rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre5_armel.deb-2 Jan 27 19:05:46 rsalveti, stupidly i made it with the same pre5 name ... Jan 27 19:05:48 apw: awesome, mine is still building =\ Jan 27 19:06:02 rsalveti, just tried a new way to copy it ... saved self 15 mins Jan 27 19:06:26 avoided a tortuos upload over my adsl Jan 27 19:06:40 nice Jan 27 19:07:50 rsalveti, just tell me it works :) Jan 27 19:08:16 we'll see :-) Jan 27 19:08:50 i suspect the testing will be as slow as the build :) its never easy to get a kernel onto one of those Jan 27 19:09:05 yeah, very slow sd card Jan 27 19:10:28 "oh no you want to save a lot of files to me ..." Jan 27 19:16:23 argh, panic while installing Jan 27 19:16:26 rebooting and trying again Jan 27 19:17:36 rsalveti, noo Jan 27 19:23:47 * apw drums his fingers in agitation Jan 27 19:24:07 Linux version 2.6.38-1-omap (root@tangerine) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.1-10ubuntu3) ) #27~pre5 Thu Jan 27 18:53:05 UTC 2011 (Ubuntu 2.6.38-1.27~pre5-omap 2.6.38-rc2) Jan 27 19:24:13 still same issue Jan 27 19:24:26 thats the rigth timestamp Jan 27 19:24:42 poop Jan 27 19:27:36 that was the only thing that is actually different at the board-omap3beagle.c from our 37 to mainline Jan 27 19:27:56 i would say i tend to concur, there is some odd ordering, but nothing 100% different Jan 27 19:28:05 s/odd/difference in Jan 27 19:28:09 yeah Jan 27 19:28:19 oh god, trashed my sd card :-( Jan 27 19:28:33 too many kernel panics while booting Jan 27 19:28:38 rsalveti, oh Jan 27 19:28:45 - if (cpu_is_omap3630()) Jan 27 19:28:45 - beagle_dvi_device.reset_gpio = 129; Jan 27 19:28:45 - else Jan 27 19:28:45 - beagle_dvi_device.reset_gpio = 170; Jan 27 19:28:45 - Jan 27 19:28:48 r = gpio_request(beagle_dvi_device.reset_gpio, "DVI reset"); Jan 27 19:28:52 is that difference significant Jan 27 19:28:57 37 has an issue with the mmc driver it seems, so sometimes giving i/o errors all around Jan 27 19:29:05 but the same logic is applied later on Jan 27 19:29:18 yeah but note, that the line after the context uses it Jan 27 19:29:30 so is the other place its added, earlier in execution Jan 27 19:30:05 beagle_display_init is the last function from omap3_beagle_init Jan 27 19:30:29 beagle_twl_gpio_setup is a .setup from beagle_gpio_data Jan 27 19:31:00 that gets registered at omap3_beagle_i2c_init Jan 27 19:31:06 + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) Jan 27 19:31:11 and probably calls the .setup Jan 27 19:31:12 - if (cpu_is_omap3630()) Jan 27 19:31:21 and we know those are the synonymous Jan 27 19:31:28 that could be another diff, but that would break a lot of stuff for xm Jan 27 19:31:39 yeah tend to agree Jan 27 19:33:37 only if .setup is not being called before beagle_display_init Jan 27 19:33:42 but need to check the callbacks Jan 27 19:33:56 rsalveti, perhaps i should just print it in the routine Jan 27 19:34:05 apw: that would do it Jan 27 19:34:06 you got a testable system if i slam in some dbg ? Jan 27 19:34:12 sure Jan 27 19:34:52 put some printks all around and lets see Jan 27 19:40:11 Out of curiosity, when will we be seeing a new omap4 kernel? Jan 27 19:40:14 rsalveti, ok building a new one with loads of output Jan 27 19:40:20 GrueMaster, thats in ti's hands Jan 27 19:40:25 (isn't it?) Jan 27 19:40:27 Ah, ok. Jan 27 19:40:34 GrueMaster: yup, ti released a new version, but not that well tested Jan 27 19:40:41 as I reported at the meeting today Jan 27 19:40:54 so they are waiting to add support for es2.2 Jan 27 19:40:59 You expect me to actually be awake for that meeting? Jan 27 19:41:01 then will probably request us to update it Jan 27 19:41:06 :-) Jan 27 19:41:21 rsalveti, what was it based on ? Jan 27 19:41:22 now for the 38 is a completely different history Jan 27 19:41:29 apw: 35 still Jan 27 19:41:44 .35 ? thats ... erm ... old Jan 27 19:42:10 hehehe Jan 27 19:42:15 that's.... ermm.... ti? Jan 27 19:42:41 they are building a landing team at linaro to care about pushing stuff upstream Jan 27 19:47:24 rsalveti, well thats something ... wonder what chance we have of having a kernel in time ... Jan 27 19:48:13 yeah, that's what worries me the most Jan 27 19:53:05 rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre6a_armel.deb Jan 27 19:53:17 let me try Jan 27 19:55:02 * apw whips rsalveti to get a result :) Jan 27 19:55:16 rsalveti, there will be much APW noise Jan 27 19:55:36 :-) Jan 27 19:57:12 rsalveti, ok have to run to the shop to get some food in ... back in 20 Jan 27 19:57:25 apw: ok Jan 27 20:06:43 apw: eeek: APW: beagle_display_init: reset_gpio=-22 Jan 27 20:07:17 the function that initializes reset_gpio is called later on Jan 27 20:07:24 so that's why Jan 27 20:08:17 so we need a patch to move this as before and also removing the settings for the hardcoded gpio Jan 27 20:08:21 the 170 one Jan 27 20:13:26 apw: http://paste.ubuntu.com/559192/ will probably be enough Jan 27 20:14:44 just need to build and test Jan 27 20:16:21 janimo_: can bug 697382 be reproduced on other arches now? Jan 27 20:16:22 Launchpad bug 697382 in pyside "ftbfs on armel" [Undecided,New] https://launchpad.net/bugs/697382 Jan 27 20:16:33 renatofilho: ^ :P Jan 27 20:16:48 GrueMaster, yes, it fauils on x86 too Jan 27 20:16:54 it is a cmake isseu from what I can tell Jan 27 20:17:03 Ok, will tag appropriately. Jan 27 20:17:19 pyside 1.0 beta4 is out but still not in debian too see if it fixes it Jan 27 20:17:46 I think doko's archive rebuild should point out if pyside fails on all archs now (if it inlcudes universe) Jan 27 20:19:33 GrueMaster, this was fixed some time ago on pyside check bug: http://bugs.openbossa.org/show_bug.cgi?id=415 Jan 27 20:19:37 bugs.openbossa.org bug 415 in PySide "phonon bindings does not build" [Major,Closed: fixed] Jan 27 20:20:13 Ok. Hasn't hit the pool yet then. Jan 27 20:20:28 renatofilho: cool, thanks :-) Jan 27 20:22:35 apw: I'm firing up another build, but it'll probably take longer than yours Jan 27 20:22:53 apw: can you try rebuilding your deb with the supposed fixes when you're back? Jan 27 20:37:09 rsalveti, just back Jan 27 20:42:07 rsalveti, ok build in progress Jan 27 21:01:50 rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre6b_armel.deb Jan 27 21:04:54 * apw pokes rsalveti Jan 27 21:08:08 apw: sorry, getting something to eat Jan 27 21:10:47 installing Jan 27 21:13:13 heh no worries Jan 27 21:18:58 apw: that error is gone, but still no display Jan 27 21:19:03 one less bug at least Jan 27 21:20:28 let me get the dmesg for you Jan 27 21:24:48 rsalveti, ok cool Jan 27 21:30:06 apw: http://paste.ubuntu.com/559224/ Jan 27 21:30:13 then same messages for omapfb Jan 27 21:40:54 hm, I don't like having a warning for an erratum Jan 27 21:41:02 just a kernel message saying it would be enough Jan 27 21:41:17 let me put more debug at omapfb Jan 27 21:43:23 seems it's not getting a proper dss device Jan 27 21:43:39 and I just noticed that we have 18 patches against dss at l-o Jan 27 21:43:45 yeah WARN is dumb as it will trigger apport etc for no reasdn Jan 27 21:44:07 rsalveti, worth looking indeed Jan 27 21:44:13 rsalveti, what timezone you in? Jan 27 21:44:34 apw: utc-2 Jan 27 21:44:53 so its near midnight ? Jan 27 21:45:02 almost 8 pm Jan 27 21:45:36 hrm ok :) thinking its food time here, but i can provide build services in the AM if thats helpful Jan 27 21:46:24 apw: sure, don't worry :-) Jan 27 21:46:44 my new build just finished, so it should be ok now Jan 27 21:48:35 excellent, speedyier once one is done Jan 27 21:48:44 i'll catch you in the morning see how it all went Jan 27 21:48:55 ok, thanks! Jan 27 22:44:39 rsalveti: Have you seen the latest patch link attached to the panda MAC bug? bug 673504 Jan 27 22:44:41 Launchpad bug 673504 in linux-ti-omap4 "Pandaboard chooses a new IP address on each boot" [High,Fix committed] https://launchpad.net/bugs/673504 Jan 27 22:45:13 THis would really be helpful for us and for the buildd pool (if it ever gets online). Jan 27 22:45:41 GrueMaster: yup, sounds fine, just didn't follow if it's upstream or not already Jan 27 22:57:45 hey guys, any reason why linux-headers does not pull in the plat-mxc/include/* stuff into the headers here? Jan 27 22:57:57 I'm just using make-kpkg and wondering if there is some clever overlay trick to it Jan 27 23:13:54 Neko, probabally an oversite as things have moved over time, if there is something needed in there then get a bug filed saying they are missing Jan 27 23:14:21 well what I'd like to do is file a bug and ship a patch at the same time Jan 27 23:14:31 but I am having trouble working out how I'd detect the scenario Jan 27 23:14:39 I can't tell what machine the kernel is built for... Jan 27 23:14:42 only the arch Jan 27 23:15:15 it seems like the whole kernel thing just never ever worked for any arm platforms and this would affect arm on debian too Jan 27 23:16:02 or worse, linux kernel doesn't do it Jan 27 23:52:39 Hey Neko in 2.6.38-rc's the mainline deb-pkg now generates linux-headers, but like make-kpkg it too only seems to generate x86 stuff.. Jan 28 00:08:02 it copies the asm stuff right but it seems any platform with a plat- and a mach- doesnt copyor link the plat-blah/include stuff into place Jan 28 00:47:34 hmn doesn't do it for omap either Jan 28 00:47:37 kernel bugggggg Jan 28 00:48:04 Indeed. This may explain a number of fail-to-build module reports on armel installs. Jan 28 00:50:17 how would you work out what the parent plat-???? directory is to the mach you're building for though, to fetch the right headers Jan 28 00:52:16 Well, linux-image-${target} could depend on linux-headers-${target}, and one could encode the requirements in the specific dependencies for linux-headers-${target} with a lookup table in the package source. That said, doing it without the packaging sugar would be lots harder. Jan 28 00:52:38 that assumes the target is directly related to the machine Jan 28 00:53:32 ah, but ${target} might support several machines? Jan 28 00:53:34 all scripts/headers.sh knows is arch, srctree, and what kind of header build it's doing (check or install) Jan 28 00:53:58 umm no Jan 28 00:54:10 but what if the target is, like in Ubuntu -generic or -server Jan 28 00:54:46 right now there's fsl-imx51 but what about fsl-imx53.. or does it get changed to fsl-mx5? Jan 28 00:55:04 that still doesn't give you a direct indication of the need for the includes from plat-mxc Jan 28 00:55:08 They're just strings, and the semantic meaning is weak. Jan 28 00:55:17 isn't what what I am saying? :D Jan 28 00:55:32 I don't want the fix to be a case block in a bash script Jan 28 00:55:38 Sure, but in practice, we assign semantics. For example, the -omap kernels only work on omap3 Jan 28 00:55:45 what about -omap4 Jan 28 00:55:48 makefile, but yeah, there ought be a better way :) Jan 28 00:55:50 seperate kernel? Jan 28 00:55:55 Currently, yes. Jan 28 00:56:28 If someone is able to make a kernel that boots both cleanly with full support, I'd expect that there would be available headers will the same level of support. Jan 28 00:56:46 currently make headers_install calls scripts/headers.sh arm arm install Jan 28 00:56:49 So if someone created -generic for armel, I'd expect that to work for nearly every device (this is probably some years off) Jan 28 00:56:57 or something similar Jan 28 00:57:24 makefile doesn't do much, in the end there's a perl script too Jan 28 00:57:53 Most of the packaging sugar is managed by debian/rules, which is traditionally a makefile, which is why I mention make. Jan 28 00:57:56 loops over files and unifdefs them Jan 28 00:58:16 debian headers rules from kernel-package makes some clever changes but it still does not handle it Jan 28 00:58:22 IMO it's a kernel bug not a packaging bug Jan 28 00:58:25 Indeed: that's the bug. Jan 28 00:58:35 it's not a packaging bug Jan 28 00:58:44 make headers_install needs to do this as well or the headers are useless Jan 28 00:58:48 I agree it's a kernel bug. It could be masked with a packaging-class fix, but fixing it in the kernel would be vastly superior Jan 28 00:58:55 mach/memory.h comes from plat- on 10 subarches of arm Jan 28 00:59:12 you can't build libc without that file Jan 28 00:59:37 there are google pages for hacks to fix bionic compilation with broken headers like that **** ENDING LOGGING AT Fri Jan 28 02:59:56 2011