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