[00:16] <jcrigby> rsalveti, just to let you know.  I have now tested the proposed u-boot with the latest x-load on panda and beagle
[00:16] <jcrigby> beagle c4
[00:17] <rsalveti> jcrigby: yeah, just tested fine on panda, xM and at my c4
[00:17] <rsalveti> I'm now booting at my b5
[00:17] <jcrigby> rsalveti, thanks for doing that
[00:27] <rsalveti> jcrigby: http://paste.ubuntu.com/593805/
[00:27] <rsalveti> at my B5
[00:29] <rsalveti> jcrigby: same sd card works fine at my C4
[00:29] <rsalveti> jcrigby: could be a regression, just don't know exactly which upload could be the culprit one
[00:29] <rsalveti> quite a while that I don't test it with my B5
[00:30] <jcrigby> hmm
[00:30] <rsalveti> let me flash a maverick sd card and we can start tracing it
[00:30] <rsalveti> want also to make sure it's not the x-loader
[00:30] <jcrigby> ok
[00:30] <rsalveti> or not a hardware issue
[00:40] <rsalveti> jcrigby: yup, 2010.09-rc1 from maverick worked fine
[00:41] <rsalveti> so it's a regression
[00:42] <jcrigby> ok, thanks
[00:42] <rsalveti> will try with the one we're using, then I can just open a bug for it
[00:43] <rsalveti> using at the image
[00:43] <rsalveti> also, let me first update just the x-loader
[00:44] <jcrigby> ok, so latest in archive is also broken?
[00:44] <jcrigby> for B5
[00:49] <rsalveti> jcrigby: trying now
[00:49] <rsalveti> jcrigby: worked fine with latest x-loader
[00:49] <rsalveti> so it's probably a regression at u-boot
[00:50] <jcrigby> ok
[00:51] <rsalveti> jcrigby: yup, broken
[00:56] <rsalveti> jcrigby: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/760350
[00:57] <jcrigby> so 2011.02.1 is also broken
[00:57] <jcrigby> rsalveti, I believe that is what is the latest in the archive right?
[00:58] <rsalveti> jcrigby: yes
[00:58] <jcrigby> and we don't  know when the regresson happend.  Just sometime between 2010.09 and 2011.02.1
[00:59] <jcrigby> rsalveti, this is going to be fun
[00:59] <rsalveti> jcrigby: haha, yeah :-)
[00:59] <rsalveti> there's also a new error with latest u-boot: timed out in wait_for_pin: I2C_STAT=0
[01:00] <rsalveti> but can be normal, probably trying to identify the expansion board
[01:00] <rsalveti> but would be good to check
[01:00] <jcrigby> yes, I saw that too, I will make sure it is expected with no expansion board
[01:01] <TheMuso> ogra_: FYI, threw in another patch from upstream for UCM. It basically enables UCM only for devices that have a UCM argument setin the udev rules, which should now cover OMAP4.
[01:01] <rsalveti> jcrigby: will be out for dinner, should be back in one hour, then we can try to bisect it
[01:02] <TheMuso> ogra_: So source should b epublished by the time you get online.
[01:03] <jcrigby> rsalveti, I will be out then so may need to wait until tomorrow.  I will be back later tonight I will ping you.
[01:04] <rsalveti> jcrigby: sure, np
[01:09] <jcrigby> sakoman, ping?
[01:15] <GrueMaster> TheMuso: Does that also cover omap?  It will have UCM support as well, hopefully by next week.
[01:15] <TheMuso> GrueMaster: Yes it does.
[01:15] <GrueMaster> Excellent.
[01:15] <TheMuso> As I said, the udev stuff is to cover omap4
[01:17] <GrueMaster> OK.  That looks like jack detection, which isn't needed for beagle/beaglexm but may be needed for other omap based systems.  Not worried about it now.
[01:18] <TheMuso> Its not jack detectino. It basically uses a definition in the pulse udev rule to tell pulse to enable UCM only for omap4, which reduces regression potential for other hadrware.
[01:18] <GrueMaster> Oh.  Hmmm.  I'll have to look over the patches again.
[01:20] <GrueMaster> This is from PA_UCM_patches_20110407.tar.bz2 right?
[01:20] <TheMuso> No, its another one that was sent to david and myself.
[01:20] <GrueMaster> Not attached to the bug?  Hate when that happens.
[01:20] <TheMuso> Its in teh package I just uploaded to my PPA.
[01:20] <GrueMaster> ok
[01:21] <TheMuso> I'll attach it to the bug if you'd like.
[01:21] <GrueMaster> It makes tracking easier, but I can find it.
[01:21] <TheMuso> ok
[01:40] <jcrigby> rsalveti: http://comments.gmane.org/gmane.linux.distributions.gumstix.general/57467
[01:40] <jcrigby> looks like multiblock reads are broken in older omap silicon
[03:06] <rsalveti> jcrigby: yeah, that makes sense
[03:07] <rsalveti> jcrigby: will try that patch
[03:15] <NCommander> rsalveti: re: IC2_ERROR, almost certian that error has to deal with the expansion port.
[03:16]  * NCommander is catching up on backscroll)
[03:16] <rsalveti> yup, probably
[03:28] <jcrigby> rsalveti, I'm going to do a patch that would be acceptable to upstream.  Something like what gcl suggests in the thread.
[03:28] <jcrigby> rsalveti, that is if it works for you
[03:28] <rsalveti> jcrigby: cool, sure
[03:43] <rsalveti> jcrigby: yup, worked fine
[03:44] <jcrigby> great!, thanks
[03:48] <rsalveti> GrueMaster: ogra_: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/760350
[03:48] <rsalveti> this should be at the beta-2 release notes
[03:48] <rsalveti> our image doesn't work with older beagles, probably <= rev B5
[03:49] <rsalveti> jcrigby: just updated the bug with the test result
[03:49] <GrueMaster> Ok.  Very odd, but I'm not sure we really even support hw <512M (except maybe headless).
[03:50] <jcrigby> GrueMaster, that might explain why this problem has never been reported
[03:51] <GrueMaster> I've seen my own issues with u-boot on beagle C4.  Currently, when I reboot I hold the user button to load x-loader & uboot from SD, but my bootcmd fails.
[03:53] <GrueMaster> bootcmd=bootcmd=mmc init;mmcinfo;if fatload mmc 0 0x82000000 boot.scr;then echo boot.scr found! Executing ...;source 0x82000000;fi
[03:54] <GrueMaster> It would fail without the mmcinfo.
[03:55] <rsalveti> GrueMaster: headless image can be useful for those old boards
[03:55] <rsalveti> GrueMaster: can be be used to be a small server, or something like that
[03:55] <GrueMaster> yes, I realize that.  That's why I dusted mine off and have it hooked up.
[03:56] <GrueMaster> I usually install openssh, and basic server.
[03:56] <rsalveti> we don't expect it to work fast, but it should at least boot :-)
[03:57] <GrueMaster> Fast is relative to the bottlenecks in the environment.  For a printerver, it should be great (haven't tested yet).
[03:57] <rsalveti> yeah
[03:58] <GrueMaster> Unfortunately, my office is in flux and need of an overhaul (hopefully this weekend).
[10:11] <ppisati> what's musb?
[10:12] <hrw> musb is TI driver for OTG port in omap2-4 chip
[10:12] <ogra_> can you use more acronyms please :P
[10:13] <ppisati> :)
[10:13] <ppisati> and, do i need a particular cable for OTG?
[10:13] <ppisati> or any usb should do it?
[10:14] <ppisati> s/usb/usb cable/
[10:14] <hrw> which board?
[10:14] <ppisati> beagle
[10:14] <ogra_> which beagle :=
[10:14] <ogra_> :)
[10:14] <ogra_> (model)
[10:15] <hrw> for device you just use normal miniusb cable
[10:15] <ppisati> beaglxm in this case
[10:15]  * hrw has only c3/b7
[10:15] <ppisati> so, can i connect the xm to my pc using the mini-usb connector? the one used to power it? is it ok?
[10:15] <ogra_> i thought linaro is drowning in XMs, they didnt gove you one ?
[10:15] <ogra_> *give
[10:16] <ppisati> anyway, i've a plain beagle too
[10:16] <hrw> yes, you can connect
[10:17] <ppisati> uhm, k
[10:17] <hrw> ogra_: do I look like a8 collector? :D
[10:17] <ppisati> because we have 2 issues here
[10:17] <ogra_> heh
[10:17] <ppisati> first, in natty we lost the musb driver
[10:17] <hrw> ogra_: I do not use beagles now
[10:17] <ogra_> who does anyway ;)
[10:17] <ppisati> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759913
[10:18] <ppisati> and the second, is that the musb is kind of broken
[10:18] <ppisati> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/608312
[10:18] <ppisati> but i can't get the a_idle state with the cable connected
[10:18] <ppisati> anyway, i'll debug it a bit more
[10:18] <ogra_> ppisati, i would recommend talking to koen on #beagle
[10:18] <ppisati> koen?
[10:19] <ogra_> he probably has fixes for such bugs in angstrom already
[10:19] <XorA|gone> musb is broken in upstream 2.6.38 kernel
[10:19] <XorA|gone> Angstrom doesnt have a fix
[10:19] <ppisati> that's a patch provided by cooloney, should work in maverick (didnt;'t try yet)
[10:19] <ogra_> XorA|gone, ah, thx
[10:19] <ppisati> but the same patch makes my board hangs at boot in natty
[10:20] <ppisati> XorA|gone: what you mean is broken?
[10:20] <XorA|gone> ppisati: will go into host mode but will never negotiate a usb address successfully with device
[10:20] <ppisati> XorA|gone: it doesn't work? it doesn't attach? it panics? it format the sd and install freebsd? :D
[10:20] <ppisati> XorA|gone: but i should get the "a_idle" state with the cable connected, right?
[10:21] <XorA|gone> ppisati: I cant rmemeber the states, it does get you all hopeful and does detect device insertion
[10:21] <ppisati> ok
[10:21] <XorA|gone> I think agreen was looking into something similar
[10:22] <ppisati> ok
[10:22] <ppisati> anyway, time to debug some more
[11:15] <ogra_> does anyone know if the usb based booting on the panda can pull the kernel via usb too ?
[11:21] <hrw> ogra_: omap4 bootrom loads xloader from usb and gives control to it - right?
[11:21] <ogra_> i think it loads MLO and u-boot
[11:21] <ogra_> but i'm not sure if u-boot then has access to the usb link to pull the kernel from there
[11:22] <hrw> probably not
[11:22] <ogra_> then i wonder whats the benefit of it
[11:22] <ogra_> if i need the SD to hold the kernel anyway, it seems to be a bit pointless
[11:23] <hrw> ogra_: if xloader is able to fetch uboot from usb then it is able to fetch kernel instead of uboot too
[11:24] <ogra_> hmm
[11:24] <hrw> and if you merge initramfs into kernel image...
[11:25] <ogra_> yes, that could probably work
[11:26] <lool> ogra_: There is a tool from TI to do this USB boot stuff
[11:27] <ogra_> lool, i know, i read the doc, but it only talks about loading MLO and u-boot
[11:27] <ogra_> and io was wondering how to then get the kernel if u-boot doesnt have USB support ...
[11:28] <ogra_> though the merged kernel/initrd instead of u-boot loading might work
[11:28]  * ogra_ tries to find an alternative way of providing PPAs without having to use the addon board 
[11:29] <ogra_> lool, i'm collecting spec ideas ... i was wondering if we should have a flash-kernel rewrite spec so we can break up the stuff into assigned work items
[11:44] <lool> ogra_: Dunno
[11:46] <doko_> janimo, ogra: armel rebuild with GCC 4.6 and binutils trunk started: https://launchpad.net/ubuntu/+archive/test-rebuild-20110419-arm/+builds?build_text=&build_state=failed
[11:46] <doko_> yes, typo in the date
[11:47] <armin76> go future
[11:48] <ogra_> looks pretty calm
[11:48] <ogra_> if you stop it now we wont have much work :P
[14:24] <ppisati> cooloney: dude, i can't musb to enter a_idle state
[14:24] <ppisati> flag@omap:~$ cat /sys/devices/platform/musb_hdrc/mode
[14:24] <ppisati> b_idle
[14:25] <sakoman> jcrigby: very belated pong :-)
[14:25] <ppisati> exactly, what do i have to do to reproduce your scenario?
[14:25] <ppisati> cooloney: lp608312
[14:25] <ppisati> i'm powering my beagle xm via the usb socket
[14:25] <ppisati> is it enough? shall i get a_idle?
[14:40] <ogra_> doko_, i see you still have an open natty WI on the armel tracker
[14:40] <ogra_> do you plan to get to that (testing xvfb on hatty) or should it probably be postponed ?
[14:41] <ogra_> (or is it done already and just missing the paperwork)
[14:43] <doko_> ogra: pointer?
[14:43] <ogra_> http://people.canonical.com/~platform/workitems/natty/ubuntu-armel.html and https://launchpad.net/ubuntu/+spec/multimedia-desktop-n-xorg-general-planning
[14:44]  * ogra_ wonders why that spec is associated at all with the armel team
[14:52] <doko_> ogra: hmm, don't know why. I appear to show up on different teams ... but it's done
[14:53] <ogra_> :)
[14:59] <rsalveti> ogra_: you can boot and get everything you need by the musb
[14:59] <ogra_> rsalveti, ah, sweet, that could be an alternbative to the addon board for PPAs then
[14:59] <rsalveti> also, there is a u-boot patchset that enables the smsc usb+eth device
[15:00] <ogra_> indeed we need a central USB server
[15:00] <rsalveti> with that we can probably use tftp
[15:00] <ogra_> cool, so lets have a BOF and spec for that in O
[15:00] <ogra_> :)
[15:00] <rsalveti> jcrigby: did you ever try this smsc patchset with your panda?
[15:01]  * ogra_ added something to the spec ideas wikipage
[15:02] <ogra_> rsalveti, btw, i think "Send the pull request to the kernel team" WI can be closed ... request was sent :)
[15:03] <rsalveti> ogra_: haha, sure, will close and put some more comment on the bug
[15:03] <ogra_> :)
[15:03] <ogra_> i guess we have to hope for an SRU here
[15:03] <ogra_> up to the kernel team though
[15:06] <rsalveti> yes, I'm planning to make another patchset, and also send it upstream at the same time
[15:06] <rsalveti> if we get good reviews, then it'll be easier to do an SRU
[15:06] <ogra_> yeah
[15:07] <rsalveti> will just update the sgx drivers again and will get back to this patchset
[15:17] <ogra_> rsalveti, oh ! i thought the WI was only omap3
[15:17] <rsalveti> ogra_: it was
[15:17] <ogra_> "send it upstream, to omap4 branch and to Linaro, to get more feedback"
[15:18] <rsalveti> ogra_: it should be included at omap 4 branch
[15:18] <ogra_> ah
[15:18] <rsalveti> to have xrandr support
[15:18] <ogra_> i thought it was already
[15:18] <rsalveti> that's fine
[15:18] <rsalveti> no, not yet
[15:18] <jcrigby> rsalveti, patchset?
[15:18] <rsalveti> upstream to get more feedback
[15:19] <ogra_> k
[15:19] <rsalveti> and linaro just to also add this functionality
[15:19] <rsalveti> ogra_: that's why I didn't create more WI for it, because the original plan was just omap 3
[15:19] <jcrigby> sakoman, google is my friend.  It was about the broken multiblock xtrers on old beagles
[15:19] <rsalveti> jcrigby: the smsc one, that adds usb+eth support
[15:19] <jcrigby> sakoman, sent a fix to list last night
[15:20] <rsalveti> jcrigby: I'm about to build and try your fix
[15:20] <jcrigby> rsalveti, oh good (on both)
[15:20]  * ogra_ sees an u-boot upload, does that already include the fix ?
[15:20] <jcrigby> rsalveti, is is patchset in history here?
[15:20] <rsalveti> jcrigby: nops, saw it at the u-boot m-l
[15:21] <jcrigby> rsalveti, oh ok, I'll go look.  I was thinking yesterday that it really is a pain to plug/unplug sd card for every kernel or u-boot rebuild
[15:23] <rsalveti> jcrigby: yes, at least tftp support would be nice
[15:24] <ogra_> no hurry though :)
[15:24] <ppisati> tftp support would be awesome
[15:24] <ogra_> hatty is nearly done
[15:24] <ogra_> *natty
[15:34] <sakoman> jcrigby: I guessed that from the discussion earlier
[15:34] <sakoman> I'll look at the list for the patch
[15:40] <rsalveti> jcrigby: yup, worked fine
[15:40] <rsalveti> jcrigby: will comment at the bug
[15:40] <jcrigby> rsalveti, fantastic
[15:40] <rsalveti> will reply with a tested-by too
[15:40] <jcrigby> great
[15:43] <rsalveti> jcrigby: ops, one bug
[15:43] <rsalveti> jcrigby: xm ES revision is ES1.0
[15:44] <jcrigby> rsalveti, crap
[15:45] <jcrigby> rsalveti, I put the ifdef in there to only get OMAP3 but I forgot about different omap3.
[15:46] <jcrigby> so if 34xx and old is the condition
[15:46] <jcrigby> then we avoid 36xx right?
[15:46] <rsalveti> jcrigby: 35xx should be fine (probably this 34xx)
[15:46] <rsalveti> jcrigby: afaik yes
[15:47] <jcrigby> ok, I'll go rev the patch, may need to ask sakoman for help
[15:47] <rsalveti> at least XM ES1.0 works fine with multi-block read
[15:47] <jcrigby> right, patch as is will just slow it down
[15:48] <sakoman> jcrigby: was just reviewing the patch and noticed the same thing
[15:49] <sakoman> I think a run time check for cpu type and revision is needed
[15:49] <jcrigby> sakoman, right
[15:49] <sakoman> since we have a single binary for both 35xx and 37xx
[15:49] <sakoman> there are still a few places in the kernel that make this same error iirc
[15:50] <jcrigby> ok, so I will leave the ifdef to leave omap4 out
[15:50] <jcrigby> and change the runtime check
[15:51] <rsalveti> yeah, that should do it
[15:51] <sakoman> there is code in sys_info.c to get cpu type and revision
[15:51] <rsalveti> I'm also afraid the same issue happens at the kernel
[15:53] <jcrigby> sakoman, for kernel it needs to be just runtime checks right?
[15:53] <sakoman> correct
[15:53] <sakoman> since we want a single omap binary
[15:53] <jcrigby> right
[15:53] <sakoman> u-boot is at least board specific, so you only need to deal with the board options
[16:03] <jcrigby> sakoman, one more dumb question, what are AM35xx devices?
[16:05] <sakoman> jcrigby: I believe that is what TI calls "Sitara"
[16:05] <jcrigby> ok, yes
[16:06] <sakoman> http://focus.ti.com/dsp/docs/dspplatformscontento.tsp?familyId=1875&sectionId=2&tabId=2643
[16:06] <jcrigby> sakoman, ok changing to	if ((get_cpu_family() == CPU_OMAP34XX) && (get_cpu_rev() <= CPU_3XX_ES21))
[16:07] <sakoman> jcrigby: seems reasonable to me
[16:07] <jcrigby> ok, thanks
[16:29] <hrw> http://www.amazon.com/dp/B004EPV7TK/ref=xs_gb_A3BWIOFSXKB0OY?_encoding=UTF8&smid=A1KWJVS57NX03I&pf_rd_p=441937901&pf_rd_s=right-1&pf_rd_t=701&pf_rd_i=20&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1JPCN2R605ZZV5R7T0DN - Tegra2 tablet for 280USD
[16:32] <rsalveti> cool
[16:38] <Sarvatt> its been abandoned by nvidia, i dont recommend it :)
[16:38]  * Sarvatt has one
[16:47] <GrueMaster> Why was it abandonded?
[16:49] <hrw> Sarvatt: harmony?
[16:49] <Sarvatt> yeah
[16:49] <Sarvatt> they moved on to a newer platform
[16:50] <hrw> http://developer.nvidia.com/tegra/forum/honeycomb-harmony
[16:50] <hrw> For our partners' Android devices, NVIDIA provides support until the hardware partner chooses to no longer support the device. So, for instance, NVIDIA will support the Xoom on all versions of Android Motorola requests until Motorola ceases to support the Xoom. The same goes for ViewSonic with the G-Tablet, Notion Ink with the Adam, Acer with the Iconia, LG with the Optimus 2X and so on.
[16:50] <Sarvatt> oh good, they updated it yesterday
[16:50] <hrw> yes
[16:51] <Sarvatt> aside from that the viewing angles on the screen are horrific on it, it really hinders using it as a tablet
[16:53] <Sarvatt> haven't been able to find a decent replacement screen for it yet because its a really thin type, something like an asus transformer is well worth the extra 130 bucks
[16:59]  * rsalveti lunch
[18:00] <GrueMaster> grrr.
[18:00] <GrueMaster> Yea!
[18:12] <zaery> what is the package name of the new onscreen keyboard
[18:14] <GrueMaster> zaery: florence
[18:15] <zaery> thx
[18:16] <GrueMaster> You should be able to find it in universe.
[18:18] <zaery> installed, but how do i start  it
[18:26] <GrueMaster> Not sure.
[18:27] <GrueMaster> There are two packages.  florence & florence-applet.
[18:27] <GrueMaster> I'll load them in a sec and test.
[18:27] <GrueMaster> what image are you working with?
[18:27] <zaery> natty x86
[18:28] <zaery> keyboard up.
[18:28] <zaery> can it auto show/hide?
[18:29] <GrueMaster> I have no idea.  I haven't worked on it or with it.
[18:29] <GrueMaster> I just remember it being packaged by a teammate.
[18:29] <GrueMaster> If you are using this on x86, why ask on #u-arm?
[18:30] <zaery> david said to talk to his guys here :)
[18:30] <GrueMaster> ah.
[18:31] <zaery> will also be looking at arm tablets soon
[18:34] <GrueMaster> Amazon is having a fire sale on the Viewsonic tablet.
[18:38] <GrueMaster> I'm not sure that florence is unity compliant.  I installed it on my netbook (amd64) and it doesn't show up in the applets icons.  I can launch it through the dash under Universal Access.
[18:41] <zaery> david couldnt remember the name. he said it was brand new
[18:41] <GrueMaster> Yea, still very early development.
[18:46] <easwar> o/
[18:46] <easwar> I'm having trouble getting Ubuntu to boot on a BB xM Rev B
[18:47] <easwar> I did the install and the boot.scr to give me a serial tty login
[18:47] <GrueMaster> Which image are you using?
[18:48] <easwar> GrueMaster, the maverick omap 3 preinstalled
[18:48] <GrueMaster> We have a headless image specifically for this purpose.  http://cdimage.ubuntu.com/ubuntu-headless/releases/natty/beta-2/
[18:48] <easwar> GrueMaster, no, I want the GUI
[18:48] <GrueMaster> The preinstalled maverick images assume you have kvm.
[18:48] <GrueMaster> Then you need to add console=/dev/tty1 as well as serial console.
[18:49] <easwar> GrueMaster, ok, and what's the deal with cdimage.ubuntu.com/ubuntu-netbook/ports/releases tree having both maverick and 10.10 as child directories?
[18:50] <easwar> which one are you supposed to select?
[18:51] <GrueMaster> For maverick on beagleXM, follow the instruvctions at https://wiki.ubuntu.com/ARM/OMAPMaverickInstall.  As to the release naming, one is a link to the other.  maverick is the codename for 10.10
[18:51] <easwar> GrueMaster, ok, so one is a symlink to the other
[18:51] <GrueMaster> Line natty is the code name for 11.04.
[18:51] <easwar> cool
[18:52] <GrueMaster> Also, there is an issue with booting the stock maverick image on beagleXM >rev A3.  They changed the hardware right at release time.
[18:52] <GrueMaster> Requires a kernel fix (which is in maverick updates) to enable video.
[18:53] <easwar> GrueMaster, that is the same as the one on the OMAPMaverickInstall page, correct?
[18:53] <GrueMaster> yes
[18:53] <easwar> downloading the kernel and uimage from rsalveti's page
[18:53] <GrueMaster> Follow the directions on the https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
[18:54] <GrueMaster> Very straight forward.
[18:54] <easwar> GrueMaster, yes, those are the ones I'm following
[18:54] <GrueMaster> For grins, you should also try the new Natty Beta 2 image (just released today).
[18:55] <GrueMaster> see /topic for link.
[19:01] <easwar> GrueMaster, might try it later, right now this is kinda (academic) project critical
[19:01] <easwar> :)
[19:01] <easwar> thanks for your help !
[19:42] <ogra_> GrueMaster, what do you think about a packaging tools profiling spec ? to identify the slow areas of dpkg/apt/update-manager
[19:42] <ogra_> (i think you suffer most from the slowness)
[19:43] <GrueMaster> I think it might get resolved with armfp, but I don't know.  I think it is related to fp emulation as opposed to hw fp.
[19:43] <ogra_> (armhf) ;)
[19:43] <GrueMaster> yea, that
[19:43] <ogra_> well, i think its a general issue on SD cards as well
[19:44] <ogra_> hardfloat will surely improve a bit here
[19:45] <GrueMaster> I get varying degrees of performance from different SD cards.  For example, package updates are 2x faster on my 8G class 10 than on the microcenter 16G class 6 cards.
[19:45] <ogra_> well, but what means 2x faster ?
[19:45] <ogra_> its still likely 3x slower than say your x86 netbook
[19:46] <GrueMaster> I'd have to run time sudo apt-get update on both with the same base image to give details.
[19:47] <GrueMaster> but even flashing the sd cards is a noticeable difference.
[19:49] <ogra_> well, then not only the same base image but the same media
[19:49] <ogra_> well, was just an idea for a possible spec
[19:51] <ogra_> its just that it feels like the whole system is totally responsive but a dist-upgrade with 120 packages takes half a day
[19:51] <GrueMaster> I think the SD size has something to do with it as well.  I flashed the omap netbook image onto a 4G microSD Class 6 at 8.0MB/s and the omap4 image on a 8G class 10 at 4.2MB/s
[19:51] <ogra_> at least thats my impression
[19:51] <GrueMaster> Yes, that is true.
[19:51] <GrueMaster> Part of it is download & SD io.
[19:52] <ogra_> i think its more the unpack/configure phase than download actually
[19:52] <GrueMaster> I see a 4-10x speed improvement using my internal mirror instead of ports.u.c.
[19:52] <ogra_> sure, we cant do much about the download speed ...
[19:52] <GrueMaster> Depending on activity/time of day.
[19:53] <GrueMaster> hence the internal mirror.
[19:53] <ogra_> but i think there is room for improvement for the debconf stuff
[19:53] <GrueMaster> Possibly.  What about btrfs support?
[19:53] <ogra_> not sure how well resizing works with it
[19:53] <rsalveti> fs benchmarks would be nice
[19:53] <ogra_> we should consider it for sure
[19:54] <ogra_> i was a bit in love with nilfs2 recently
[19:54] <GrueMaster> I remember it was argued against in maverick as it was still too early, and that carried forward with natty while we still had .35 based kernels.
[19:54] <ogra_> but it has no resize options at all :(
[19:54] <GrueMaster> ouch.
[19:54] <ogra_> i have seen measurements that show its even faster than btrfs
[19:55] <ogra_> and its a snapshot based fs
[19:55] <GrueMaster> ext3 faster than btrfs?
[19:55] <ogra_> you can roll back to any state you like
[19:55] <GrueMaster> Ah.
[19:55] <ogra_> ext3 is slower than btrfs i think
[19:55] <ogra_> at least on SD
[19:55] <ogra_> btrfs has specific SD optimizations
[19:56] <GrueMaster> I know there is a conversion tool.  Wonder if it could be added to jasper.
[19:56] <ogra_> so it would actually be good to switch, but its a question of stability and feature completeness
[19:57] <GrueMaster> Definately some things to test in early Oneric alpha.
[19:57] <ogra_> we should find out what the actual last blocking factors are in ubuntu
[19:57] <ogra_> if its just some grub issues we dont need to care for example
[19:57] <ogra_> i'm not sure conversion is such a good idea
[19:58] <GrueMaster> That was on the n900 kubuntu-mobile wiki.
[19:58] <ogra_> you are gambling with the users data ...
[19:58] <GrueMaster> https://wiki.ubuntu.com/ARM/n900
[19:58] <GrueMaster> The conversion could be run after grow-root. No user data to implode.
[19:59] <GrueMaster> I can do some experiments on it, but I should see about getting alsa-ucm support for beagle first.
[20:01] <ogra_> yeah, thats all oneric ...
[20:01] <ogra_> note it down as idea though :)
[20:04] <GrueMaster> Added to wiki.
[20:04] <ogra_> awesome
[20:22] <ogra_> GrueMaster, i have changed the monimal size req for headless from 4 to 2G on the wikipage
[20:22] <GrueMaster> Ok.
[20:22] <ogra_> (for headless thats sufficient)
[20:22] <GrueMaster> Hrm.  Looks like btrfs is still in flux.
[20:22] <ogra_> yeah
[20:22] <ogra_> still not default in ubuntu
[20:23] <ogra_> i think arnd from
[20:23] <GrueMaster> Beyond that.  They haven't finalized the format.
[20:23] <ogra_> #linaro works upstream
[20:23] <GrueMaster> https://btrfs.wiki.kernel.org/index.php/Main_Page
[20:24] <ogra_> well, the warning is for .31
[20:24] <ogra_> we'll be at 39 or 40 in oneric
[20:24]  * ogra_ goes to make some meeting coffee
[20:25] <GrueMaster> v2.6.37 (January 2011) On-disk free space cache, asynchronous snapshots, unprivileged subvolume deletion, extent buffer switches from a rbtree with spinlocks to a radix tree with RCU.
[20:25] <GrueMaster> From the changelog.
[20:28] <ogra> yep
[20:30] <ogra> line is up
[20:30] <ogra> ergh