=== asac_ is now known as asac [09:58] did someone had keyboard-configuration hang on postinst on panda? [10:01] sveinse: have a moment to discuss bug 683832? [10:01] Launchpad bug 683832 in gcc-4.5-armel-cross "gcc fails to cross compile Qt" [Undecided,Confirmed] https://launchpad.net/bugs/683832 [10:02] Yes, I do [10:03] sveinse: did you tried to compile in ARM mode? [10:03] sveinse: Thumb2 is default [10:04] hrw, Yes, that works. However I'm if it has any performance impact [10:05] sveinse: for Thumb2 mode you need to check ubuntu qt patches [10:05] there were some for it iirc [10:06] hrw, console-setup being broken is a known issue and not arm specific [10:06] as this bug is a bug in Qt not in gcc [10:07] ogra: ok, but it hangs only on arm for me so thats why I asked here [10:07] no idea whats the workarouns [10:07] ogra: rm /var/lib/dpkg/info/keyboard-configuration.postinst ;d [10:07] if you upgrade to natty you get about 20 requests to configure your kbd [10:07] hrw, Yes. Qt does have some fixes for the thumb2 issue which I have also tried [10:08] ogra: I am on natty [10:08] However it fails during early compilation. Let me see if I can find the error. [10:08] and yes, console-setup is insane [10:08] anyway... console-setup does not even lists my keyboards ;S [10:08] hrw, when do you run the keyboard configuration then if you are on natty ? [10:09] hrw, The reason I'm mentioning this is I'm suspecting some difference between CSL and Linaro/ubuntu gcc [10:09] the issue is that some value is missing in /etc/default/console-setup [10:09] ogra: during "apt-get upgrade" [10:09] ah, k [10:09] sveinse: I think that csl defaults to -marm, ubuntu defaults to -mthumb [10:09] well, thats the same i get when upgrading from maverick then [10:11] hrw, i think its CHARMAP or CODESET being empty that causes this [10:11] hrw, but for your inital question -marm fixed the compilation as such [10:17] ok [10:17] 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) [10:18] sveinse: "xapt install lib1 lib2 lib3" + configure + make [10:19] hrw, lib1 lib2 lib3 being the libxxx-dev build-depends to the software you're building, right? [10:21] yes [10:21] elegant! [10:21] works under natty, no idea about maverick === dmart__ is now known as dmart [10:26] hrw, why doesnt xapt-get build-dep work ? [10:26] no idea? [10:26] i.e. why doesnt it just stick to apt syntax [10:29] good question [10:29] probably fast written tool while waiting for multiarch [10:33] heh [10:34] hrw: hang > that sounds like very very slow perl, I had that a while ago; maybe it's something else though [10:35] lool: I just removed postinstall scripts [10:36] lool: a4tech keyboard which I use do not require extra config. and is not listed in console-setup list anyway [11:18] 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: [11:18] {standard input}: Assembler messages: [11:18] {standard input}:527: Error: thumb conditional instruction should be in IT block -- `strexeq r2,r5,[r6]' [11:18] {standard input}:528: Error: thumb conditional instruction should be in IT block -- `teqeq r2,#1' [11:18] Now, I dont know if this is related to GCC or if its a qt issue. Is this familiar? [11:19] familiar [11:19] moment [11:19] check bug 675347 [11:19] Launchpad bug 675347 in gcc-linaro "volatile int causes inline assembly build failure" [Medium,In progress] https://launchpad.net/bugs/675347 [11:20] no, it is rather bug 682742 [11:20] 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 [11:21] hm.. not this too [11:21] there was a bug about it... [11:21] :D [11:22] bug 490371 [11:22] Launchpad bug 490371 in qt4-x11 "Atomic operations not safe for ARMv7,Thumb-2 and multicore" [Medium,In progress] https://launchpad.net/bugs/490371 [11:23] also bug 673085 [11:23] 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 [11:24] What is the difference of armv6 and armv7? Because the qt fix in 490371 is agains armv6 it seems [11:25] there is a new QT coming this week i was told [11:25] that might fix some of these issues [11:25] Could check the beta, unless it's a fix since then [11:25] ogra, we're using git, not the official snapshots/releases [11:26] and the armel compilation issue is still present in the head of their branches [11:26] sveinse: there were no optimizations for armv7 in Qt so armv6 ones are used or sth like that [11:27] I'm a little surprised that qt doesn't fix this, armel build for qt must surely be focus area for nokia [11:29] erm, indeed, our package sets -march=armv6 [11:35] I think I shall check out the qt source package to see if there are any other relevant qt patches for armel [11:35] i think there are a bunch [11:35] probably also check other projects for their patches [11:37] yeah, checking OE usually makes sense for arm patches [11:40] ogra: and vice versa ;D [11:40] ogra: OE has Debian, Ubuntu, Gentoo, Fedora patches [11:40] well, i wouldnt really care for the armv5 patches of debian or fedora [11:51] 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) [12:34] hrw, Do I understand that I should be the one to close bug 683832 ? [12:34] Launchpad bug 683832 in gcc-4.5-armel-cross "gcc fails to cross compile Qt" [Undecided,Confirmed] https://launchpad.net/bugs/683832 [12:36] sveinse: I prefer you to be one, or I can mark it as invalid [12:41] hrw, done [12:41] thx === rsalveti is now known as rsalveti_ === rsalveti` is now known as rsalveti [14:33] bug 684148 [14:33] ogra: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/684148) [14:49] LP #684148 [14:49] Launchpad bug 684148 in unity-2d "[i18n] integrate gettext and use translations from Unity" [High,Triaged] https://launchpad.net/bugs/684148 [14:49] Ah [15:04] ogra: did you move the image script for omap4 to get the new x-loader from the new package? [15:04] ogra: then we can request the removal of x-loader-omap4 [15:05] rsalveti, can you check if it actually ends up on the image ? [15:06] (yes, i did change the scripts) [15:06] ogra: sure, just wanted to ask you first, as I know you changed for omap3 [15:06] but don't know for omap4 [15:06] will check the logs [15:07] i changed both at the same time [15:07] cool, so we should be fine [15:30] 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? [15:30] ogra, i've got some new kernels previews you might like to test: http://people.canonical.com/~apw/misc/arm/ [15:30] apw: why preview? [15:30] what is special about this kernel? [15:31] 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 [15:31] so these are hand built for earlier access [15:31] apw: oh, ok, cool [15:31] will give it a try now [15:43] weee, kernel panic while installing new deb hehe [15:43] * rsalveti is trying again [15:57] ogra: ac100 has sata internally used? [15:58] no [15:58] ogra: emmc storage? [15:58] yep [15:59] apw: eeek, not good [16:00] thx ogra [16:00] rsalveti, s'up [16:00] apw: http://paste.ubuntu.com/559064/ [16:00] warning but later on failed to start omapfb [16:00] so, no display [16:00] rsalveti, not sure if the warning matters per-see [16:01] not having a framebuffer looks more annoying [16:01] yeah, don't know if they are related atm, need to properly check the code [16:01] rsalveti, yeah [16:02] well, at least some fun debugging time for later today [16:04] rsalveti, yeah :) we have a couple of days (well two i guess) before we freeze for A2 [16:06] apw: ok, ping you back if I get any other news about it [16:06] Hey all. [16:07] rsalveti, thanks ... i note there is exactly one commit between v2.6.37 and the tip for omapfb [16:07] Going from ubuntu netbook version to ubuntu desktop is just a matter of removing ubuntu-netbook package and installing ubuntu-desktop, right? [16:08] apw: cool, just checkout out the git tree [16:11] rsalveti, ok that warn_on is telling you you have an erratum [16:11] if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) { [16:12] rsalveti, any idea what graphics driver one should have? [16:12] Wow. Firefox is using 172% of cpu on omap4, reporting an oem-config crash bug. [16:17] rsalveti, do you have the whole of the dmesg [16:18] apw: not yet, checking the code atm [16:18] apw: sure, 1 sec [16:21] apw: http://paste.ubuntu.com/559074/ [16:22] [ 0.147460] Unable to get DVI reset GPIO [16:23] [ 4.675109] regulator_init_complete: VPLL2: incomplete constraints, leaving on [16:23] [ 4.682983] regulator_init_complete: VDAC: incomplete constraints, leaving on [16:24] commit f8362d215549c66066f78e67c033dd370ae50322 [16:24] Author: Koen Kooi [16:24] Date: Tue Jan 11 17:13:36 2011 +0000 [16:24] omap3: beaglexm: fix DVI reset GPIO [16:24] rsalveti, th [16:25] rsalveti, though we _have_ that in the kerenls you are running [16:25] rsalveti, is this an XM or regular [16:25] XM [16:29] rsalveti, i idly wonder if yours is on the other gpio number [16:31] rsalveti, the v2.6.37 based kernel worked on your xM didn't it? [16:31] rsalveti, diffing to there there is no mention of the 129 gpio in the code before [16:32] apw: 37 worked fine [16:32] 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 [16:32] apw: yup, login works fine [16:33] rsalveti, i think i might suggest that you try as a first stab making this bit always use 170 [16:33] + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) [16:33] + beagle_dvi_device.reset_gpio = 129; [16:33] + else [16:33] + beagle_dvi_device.reset_gpio = 170; [16:33] as i think in 27 it always used 170 for all beagles [16:34] static struct omap_dss_device beagle_dvi_device = { [16:34] .type = OMAP_DISPLAY_TYPE_DPI, [16:34] [...] [16:34] - .reset_gpio = 170, [16:34] was the old .27 code [16:36] apw: at maverick we have this change, but differently [16:36] but also using 129 for xm [16:36] so it should be fine [16:37] but weird that it worked fine for 37 [16:37] if it was only using 170 [16:37] rsalveti, welll not necessarily [16:37] static int beagle_enable_dvi(struct omap_dss_device *dssdev) [16:37] { [16:37] if (gpio_is_valid(dssdev->reset_gpio)) [16:37] gpio_set_value(dssdev->reset_gpio, 1); [16:37] return 0; [16:37] as the platform init does that [16:38] on maverick the reset_gpio was struct was set as 170 [16:38] but then we had a check at beagle_display_init [16:38] then then set it correctly if it's a xm [16:39] *that then [16:39] but then that other check may occur in time before it or something [16:39] so 37 probably had something similar [16:40] using the diff from v2.6.37 and the tip of natty 129 does not appear with a - [16:40] ie if it was there its still there [16:43] rsalveti, we might also consider putting the failed gpio pin number in the error on failure [16:43] might help know if its an init ordering issue [16:45] rsalveti, hrm how much did you miss i wonder [16:45] let me check the logs from bip [16:46] rebooting my host pc, got dead for some unknown reason [16:46] natty [16:46] hrm [16:46] still 37 :-) [16:46] but with btrfs [16:46] :) good [16:46] :( bad [16:47] yeah :-( [16:48] rsalveti_, so any oppinion as to what debug to shove in, and will you do it, or do you need me to make kernels [16:48] don't worry, I can check this here [16:48] and easily cross build the kernel [16:49] ok cool ... i guess we are at 'have h/w will debug stage' so i'll get out your hair [16:49] ok, ping you back with more results later [16:49] thanks anyway [16:49] where do you have his hair ? in a drawer ? [16:50] * ogra imagines apw with a rsalveti wig [16:50] rsalveti, :) thanks [16:50] ogra, with mine yep :) [16:50] *g* [16:52] 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 :) [16:52] apw: sure, np [16:59] 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 [17:20] GrueMaster: hehe [17:21] GrueMaster: i suspect it isn't going to be quad core [17:21] GrueMaster: first versions probably with just be dual core [17:22] I just saw the article and the mention of quad core Cortex-A9. I have no detailed specs yet, but haven't looked either. [17:49] 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? [18:04] * apw wonders how rsalveti is getting on :) [18:07] apw: waiting a build to finish, to properly check what's happening, my host seems quite unstable atm :-( [18:07] had to reboot 2 times already [18:07] apw: how is the 38 testing going? [18:07] * rsalveti thinking about changing to 38 [18:08] but heard people were facing lots of issues with it [18:08] rsalveti, ahh how long does it takeing [18:08] my machines here are running .38 based kernels, previews like the arm ones, but i'd not say i was stressing them [18:09] apw: hm, what are you running at your desktop? [18:09] 38? [18:09] this machine is back furhter than that [18:10] my other smaller boxses are on the preview though [18:10] running unity, when it works [18:10] hehehe [18:10] mine is very broken [18:11] using classic desktop atm, with metacity instead of compiz 2d [18:11] so this machine is all uptodate, including the upcoming kernel [18:11] and its holding together mostly, well as long as you remeber to right click to get the menus working [18:12] hehe, cool, maybe will update mine later on [18:12] today [18:12] but i've not got the guts to put it on my bigger machine as i am not yet ready for the paradigm shift [18:13] just about to do an update on a desktop [18:14] something to check later is why it's powering DVI down using 170 as a hardcoded value at omap3_beagle_init [18:15] while when starting up it checks if it's running xm or not, and select the proper gpio pin [18:16] don't know what is connected to 170 at xm [18:16] need to check the hw docs [18:37] rsalveti, this bit you mean: [18:37] omap_mux_init_gpio(170, OMAP_PIN_INPUT); [18:37] gpio_request(170, "DVI_nPD"); [18:37] /* REVISIT leave DVI powered down until it's needed ... */ [18:37] gpio_direction_output(170, true); [18:37] looks like it should be using the reset_gpio as well indeed [18:38] yup [18:38] maybe... hard to tell it does use different descriptions [18:38] as if 170 is power and 129 is reset on xm, but both on !xm [18:39] all depends on semantics i guess [18:39] the docs sounds like ones freind here for sure [18:43] rsalveti, the below sounds bad: [18:43] "Passing invalid GPIO numbers to gpio_request() will fail, as will requesting [18:43] GPIOs that have already been claimed with that call." [18:43] as far as i can tell for !xm we would request 170 twice and violate that [18:44] which would lead to that error ... [18:44] hm, makes sense [18:45] on maverick this was remove with commit 8c3818913431c5ae62a7e56a38d38c4ca81ee4a2 [18:45] let me check 37 [18:46] rsalveti, oh yeah its removed ... hrm [18:47] * rsalveti is still waiting his build to finish [18:47] rsalveti, how long do they take ? [18:48] this is the first one, then I can just make what changed [18:48] but 30 min probably [18:48] apw: if it's faster for you, can you try removing that out and build it again? [18:48] rsalveti, about the same once i've pushed it so you can get to it [18:49] omap_mux_init_gpio(170, OMAP_PIN_INPUT); [18:49] gpio_request(170, "DVI_nPD"); [18:49] /* REVISIT leave DVI powered down until it's needed ... */ [18:49] gpio_direction_output(170, true); [18:49] seems it was in there for .37 [18:49] which is perplexing [18:49] hm, not from one I'm seeing here [18:49] from Ubuntu-2.6.37-9.22 [18:49] let me check again [18:50] git show Ubuntu-2.6.37-9.22:arch/arm/mach-omap2/board-omap3beagle.c [18:50] sounds fine [18:50] yeah [18:50] yep clearly new... [18:50] shall i build without that in parallel ? [18:51] apw: sure [18:53] 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 [18:54] apw: yup, the same patch that changes to use 129 is the one who removes this piece [18:54] and you got a conflict and probably just removed the patch [18:55] 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 [18:55] rsalveti, heres hoping thats the main issue [18:56] if i had been diffing to a sensible place for .37 i'd have noticed that too ... silly me [19:05] rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre5_armel.deb-2 [19:05] rsalveti, stupidly i made it with the same pre5 name ... [19:05] apw: awesome, mine is still building =\ [19:05] rsalveti, just tried a new way to copy it ... saved self 15 mins [19:06] avoided a tortuos upload over my adsl [19:06] nice [19:07] rsalveti, just tell me it works :) [19:08] we'll see :-) [19:08] i suspect the testing will be as slow as the build :) its never easy to get a kernel onto one of those [19:08] yeah, very slow sd card [19:10] "oh no you want to save a lot of files to me ..." [19:16] argh, panic while installing [19:16] rebooting and trying again [19:17] rsalveti, noo [19:23] * apw drums his fingers in agitation [19:23] 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) [19:24] still same issue [19:24] thats the rigth timestamp [19:24] poop [19:27] that was the only thing that is actually different at the board-omap3beagle.c from our 37 to mainline [19:27] i would say i tend to concur, there is some odd ordering, but nothing 100% different [19:27] s/odd/difference in [19:27] yeah [19:28] oh god, trashed my sd card :-( [19:28] too many kernel panics while booting [19:28] rsalveti, oh [19:28] - if (cpu_is_omap3630()) [19:28] - beagle_dvi_device.reset_gpio = 129; [19:28] - else [19:28] - beagle_dvi_device.reset_gpio = 170; [19:28] - [19:28] r = gpio_request(beagle_dvi_device.reset_gpio, "DVI reset"); [19:28] is that difference significant [19:28] 37 has an issue with the mmc driver it seems, so sometimes giving i/o errors all around [19:28] but the same logic is applied later on [19:29] yeah but note, that the line after the context uses it [19:29] so is the other place its added, earlier in execution [19:29] beagle_display_init is the last function from omap3_beagle_init [19:30] beagle_twl_gpio_setup is a .setup from beagle_gpio_data [19:30] that gets registered at omap3_beagle_i2c_init [19:30] + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) [19:30] and probably calls the .setup [19:31] - if (cpu_is_omap3630()) [19:31] and we know those are the synonymous [19:31] that could be another diff, but that would break a lot of stuff for xm [19:31] yeah tend to agree [19:33] only if .setup is not being called before beagle_display_init [19:33] but need to check the callbacks [19:33] rsalveti, perhaps i should just print it in the routine [19:33] apw: that would do it [19:33] you got a testable system if i slam in some dbg ? [19:34] sure [19:34] put some printks all around and lets see [19:39] Out of curiosity, when will we be seeing a new omap4 kernel? [19:40] rsalveti, ok building a new one with loads of output [19:40] GrueMaster, thats in ti's hands [19:40] (isn't it?) [19:40] Ah, ok. [19:40] GrueMaster: yup, ti released a new version, but not that well tested [19:40] as I reported at the meeting today [19:40] so they are waiting to add support for es2.2 [19:40] You expect me to actually be awake for that meeting? [19:40] then will probably request us to update it [19:40] :-) [19:41] rsalveti, what was it based on ? [19:41] now for the 38 is a completely different history [19:41] apw: 35 still [19:41] .35 ? thats ... erm ... old [19:41] hehehe [19:42] that's.... ermm.... ti? [19:42] they are building a landing team at linaro to care about pushing stuff upstream [19:47] rsalveti, well thats something ... wonder what chance we have of having a kernel in time ... [19:48] yeah, that's what worries me the most [19:52] rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre6a_armel.deb [19:53] let me try [19:54] * apw whips rsalveti to get a result :) [19:55] rsalveti, there will be much APW noise [19:55] :-) [19:57] rsalveti, ok have to run to the shop to get some food in ... back in 20 [19:57] apw: ok [20:06] apw: eeek: APW: beagle_display_init: reset_gpio=-22 [20:07] the function that initializes reset_gpio is called later on [20:07] so that's why [20:08] so we need a patch to move this as before and also removing the settings for the hardcoded gpio [20:08] the 170 one [20:13] apw: http://paste.ubuntu.com/559192/ will probably be enough [20:14] just need to build and test [20:16] janimo_: can bug 697382 be reproduced on other arches now? [20:16] Launchpad bug 697382 in pyside "ftbfs on armel" [Undecided,New] https://launchpad.net/bugs/697382 [20:16] renatofilho: ^ :P [20:16] GrueMaster, yes, it fauils on x86 too [20:16] it is a cmake isseu from what I can tell [20:16] Ok, will tag appropriately. [20:17] pyside 1.0 beta4 is out but still not in debian too see if it fixes it [20:17] I think doko's archive rebuild should point out if pyside fails on all archs now (if it inlcudes universe) [20:19] GrueMaster, this was fixed some time ago on pyside check bug: http://bugs.openbossa.org/show_bug.cgi?id=415 [20:19] bugs.openbossa.org bug 415 in PySide "phonon bindings does not build" [Major,Closed: fixed] [20:20] Ok. Hasn't hit the pool yet then. [20:20] renatofilho: cool, thanks :-) [20:22] apw: I'm firing up another build, but it'll probably take longer than yours [20:22] apw: can you try rebuilding your deb with the supposed fixes when you're back? [20:36] rsalveti, just back [20:41] rsalveti, ok build in progress [21:01] rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre6b_armel.deb [21:04] * apw pokes rsalveti [21:07] apw: sorry, getting something to eat [21:10] installing [21:13] heh no worries [21:18] apw: that error is gone, but still no display [21:18] one less bug at least [21:20] let me get the dmesg for you [21:24] rsalveti, ok cool [21:29] apw: http://paste.ubuntu.com/559224/ [21:30]