[00:54] <Sarvatt> pixman in maverick is muuch faster on arm, I merged that as soon as I could :)
=== robclark1 is now known as robclark
[08:01] <kai> hi folks
=== hrw|gone is now known as hrw
[08:13] <hrw> morning
[08:16] <kai> is there much of a difference in assembler code between armv5 and the newer systems like the cortex (apart from the stuff the newer systems add)?
[08:17] <kai> one of my co-workers is fiddling around with low-level kernel calls to get async file io going, and I'm wondering if I should get him an account on a shevaplug (faster, more ram) or on a beagle (newer cpu arch)
[09:00] <lool> kai: Depends whether he's optimizing for v6 or v7?
[09:01] <lool> kai: beagle's speed is decent, but I never tried the JTAG; sheeva is really great to JTAG-debug, so it might be relevant for him
[09:01] <Lutin> lool: if it's a matter of getting things /going/ , v6 vs. v7 shouldn't matter much though
[09:02] <lool> Lutin: the question is sheeva versus beagle, I agree with you that the described work is likely not architecture specific, but apparently it's about writing some assembler, so it could make a difference
[09:03] <hrw> Lutin: v5 vs. v7
[09:03] <lool> if you want to ship a v7 based product and you dont care that your code works on v5, you might be able to use some v6 or v7 assembly to speed things up
[09:03] <hrw> sheeva has armv5
[09:05] <kai> lool: I don't actually know what's involved
[09:06] <kai> lool: this is about some really low-level IO stuff in the linux kernel, that's about the point where the explanation turned into chinese
[09:06] <hrw> kai: sheeva + jtag access then would be easier and faster
[09:08] <kai> hrw: ok, thanks :)
[09:08] <hrw> sheeva cpu if much faster in integer then beagleboard
[09:09] <hrw> and in kernel you can not use vfp or neon so no big speed up would be archived on bb
[09:12] <hrw> shit. dpkg hang on my dekstop
[12:37] <amitk> ogra_cmpc: what is the equivalent of qemu-arm-static in debian?
[12:49] <lool> amitk: qemu-user-static
[12:52] <amitk> lool: thanks
[14:23] <lool> mpoirier: Heya
[14:23] <mpoirier> good day.
[14:23] <lool> mpoirier: linux-image-omap depends on linux-image-2.6.33-500-omap in maverick
[14:24] <mpoirier> ?
[14:24] <lool> mpoirier: Currently, linux outputs linux-image-2.6.35-4-omap
[14:24] <lool> mpoirier: There are two set of omap kernels in maverick
[14:24] <lool> mpoirier: One built from linux, and one built from linux-ti-omap
[14:24] <mpoirier> humm....
=== kmargar is now known as markos_
[14:24] <lool> apt-get install linux-omap or linux-image-omap should do something useful, but is broken right now
[14:25] <mpoirier> Humm....
[14:25] <lool> mpoirier: It's not clear to me whether you'll switch to a separate branch + source package for omap4 support, or whether it will still be linux source package?
[14:25] <mpoirier> it is still undecided.
[14:26] <lool> Humm....
[14:26] <mpoirier> according to the trail of email in my inbox over the last couple of days
[14:26] <lool> mpoirier: Is there any benefit for OMAP3 in running the OMAP branch from TI?
[14:27] <lool> If you get a single binary kernel to work on OMAP3 + OMAP4 from the TI branch and it's strictly better than the mainline one, then I think the path is clear
[14:27] <mpoirier> indeed.
[14:28] <mpoirier> mainline should follow quickly though...
[14:29] <amitk> lool: omap4 support will come out of separate source tree (it resides as a branch in the maverick kernel)
[14:29] <amitk> tim added it yesterday
[14:31] <lool> amitk: Yes, understood this bit; was it decided to use a single kernel for OMAP4 and OMAP3?  and is there any regression for OMAP3 from mainline to the TI branch?
[14:31] <amitk> lool: there is not benefit is running omap3 with TI's code since TI's code is not upstream and hence will get refactored quite a bit before it all makes it to upstream.
[14:31] <amitk> also, last I looked, TI's tree breaks OMAP3
[14:31] <lool> Ok
[14:52] <ogra> lool, bug 595949
[14:52] <ubot2> Launchpad bug 595949 in linux-meta-ti-omap (Ubuntu Maverick) (and 1 other project) "linux-meta-ti-omap depends on the wrong binary kernel in maverick (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/595949
[15:00] <lool> ogra: Thanks; I didn't know whether linux-meta was also concerned or not
[15:34] <hrw> http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ -  new structure, new versions
=== bjf[afk] is now known as bjf
=== hrw is now known as hrw|gone
[17:32] <sebjan> ogra: I just filed the bug 596004 regarding the UNE UI issue on Maverick
[17:32] <ubot2> Launchpad bug 596004 in netbook-meta (Ubuntu) "with 2D UI (une-efl) selected, the gnome desktop toolbar is also visible and seems to be running (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/596004
[17:38] <ogra_cmpc> sebjan, great, thanks, i'll take care of it
[17:42] <lool> Wow, my beagle has a /dev/ramzswap0 for some reason
[17:42] <lool> is compcache enabled on installed system as well?  i thought it was an install only thing
[17:47] <markos_> lool: hi, I have some initial results on the hardfp/softfp performance
[17:47] <markos_> tested on the iMX515 with karmic (ubuntu original vs my compiled with hardfp)
[17:48] <markos_> I tested glxgears to see how it would affect fp performance (using fbdev X, no 2d/3D accel)
[17:48] <markos_> so softfp gave me ~120 fps, while hardfp gives me 146 fps
[17:49] <markos_> I know glxgears is not a proper 3D benchmark, but I'm not interested in 3D, rather fpu performance
[17:49] <markos_> so...
[17:49] <markos_> that's ~21% speed increase, dunno if it can be more, but it looks logical
[17:50] <markos_> I'll post this asap with more info
[18:03] <lool> markos_: markos_ That's interesting, thanks
[18:03] <lool> markos_: what about the archive, did you manage to setup a source one?
[18:04] <markos_> yeah it includes sources in the same url
[18:04] <markos_> most of them at least
[18:05] <markos_> I probably forgot to include sources for packages I built manually -not needing patching, just cyclic dependency probs,e tc
[18:09] <lool> markos_: http://freevec.org/repository/dists/karmic/main/ has no source index?
=== sbambrough is now known as sbambrough-lunch
[18:12] <markos_> strange, I did reprepro includedsc
[18:12] <markos_> lol
[18:12] <markos_> that was on my local server, I have to rsync it
[18:12] <markos_> sorry bout that :)
[18:13] <markos_> I'll let you know when the rsync is over
[18:16] <lool> markos_: thanks a lot
[18:17] <lool> markos_: I'm away next week though, so I'll probably mirror the week afterwards
[18:18] <markos_> i don't think it's going anywhere
[18:18] <markos_> I mean I have no plans to move or remove it
[18:18] <markos_> so...
[18:19] <lool> Ok thanks
[18:23] <markos_> the past days I've been working on setting up wanna-build...
[18:23] <markos_> I have to say the documentation is *crap*
[18:23] <markos_> I still haven't managed to even setup the db
[18:23] <markos_> anyway, dinner time, later
=== sbambrough-lunch is now known as sbambrough
=== JaMae is now known as JaMa
[19:40] <GrueMaster> ogra: ping.  Do you know when jasper will be in the repo?
[21:05] <lool> markos_: An alternate wanna-build is being developed IIRC
[21:05] <lool> markos_: pkern was doing a python rewrite as a gsoc I thnk
[21:05] <lool> markos_: The documentation for the current version is the source I'm afraid