[08:32] <MrCurious> is there a way to predict when the next version of ubuntu after 11.04 will be released
[08:32] <MrCurious> for arm :D
[08:32] <MrCurious> i am seeing usb speed issues on 11.04. can anyone replicate?
[08:35] <ogra_> https://wiki.ubuntu.com/OneiricReleaseSchedule+
[08:36] <ogra_> err
[08:36] <ogra_> https://wiki.ubuntu.com/OneiricReleaseSchedule
[08:36] <ogra_> 11.10 daily images are on cdimage.ubuntu.com
[08:38] <MrCurious> ty
[09:13] <sveinse> I'm trying to migrate my target system to natty, but I'm having some problems with cross compilation. It seems like libs like libpthread.so.0 and libdl.so.2 are moved to /lib/arm-linux-gnueabi/. OOI why is it done this way?
[09:22] <persia> sveinse, I'm not entirely sure, but suspect it's fallout from multiarch.
[09:23] <persia> How are you migrating?
[09:23] <sveinse> Well, as discussed earlier, I'm building the rootfs with rootstock (which seems to work)
[09:24] <sveinse> The problems are because my cross compilation of a Qt app fails
[09:24] <sveinse> It can't find libpthreads.so.0 by itself anymore
[09:24] <persia> Are you using hrw's cross compilation environment?
[09:25] <sveinse> No, we've made our own. Are you thinking of xdeb or xapt ?
[09:26] <persia> No.  hrw put together some cross-toolchain packages, which seem to behave sanely.
[09:26] <sveinse> Do you where I can find it?
[09:26] <persia> But I don't know much about them (I avoid cross compilation)
[09:27] <persia> I think one just installs "gcc-arm-linux-gnueabi" on an i386 or amd64 system.
[09:28] <sveinse> Yes, I know. But still cross compilation is neccessay/useful. Qt for example is built for cross compilation
[09:28] <persia> Well, we don't build it that way :)
[09:28] <persia> (but, yes, I know)
[09:28] <persia> I'm not convinced that the combination of cross-compiled and native-compiled has been extensively tested, nor that there is consistent ABI.  I may be mistaken, and I'd be happy if someone did the research to confirm they are the same.
[09:28] <sveinse> Oh yes, of course. It is gcc-arm-linux-gnueabi we're using. The beauty of that cross compiler is that it's configured the same way as the armel native couterpart
[09:30] <sveinse> armel cross compilation is an experienced area in gcc. In fact it has existed even longer as cross compiler than the native version
[09:30] <sveinse> It just recently it has become possible to compile armel code natively
[09:30] <persia> Oh, I know.
[09:30] <persia> The cross-compiler is likely more mature.
[09:31] <persia> MY concern is about mixing (well, also about having everything behave the same so I can ignore which architecture I'm using)
[09:31] <sveinse> So I have no distrust in gcc in that respect. And the issue I have is related to linker search paths, I believe
[09:31] <persia> But I'm a bit of a crank about this: feel free to ignore me :)
[09:31] <persia> I *thought* hrw's linker was multi-arch aware.  Hrm.
[09:31] <persia> Maybe catch him when he's around.
[09:32] <sveinse> Surely object, I don't mind (except if it takes me away from my task :D )
[09:33] <sveinse> In fact, I'd rather merge over to native compilation. But recompiling Qt is a *heavy* task, and we do that a lot (We're not using X11)
[09:33] <sveinse> And such, Qt and our apps are cross build using the armel cross compiler
[09:33] <persia> Right.  In your very special case, I think you're probably doing the least painful way.
[09:33] <persia> In general, I think folk ought use X :)
[09:34] <sveinse> Yes, agree. Unfortunately our target (OMAP3) does not have any accelerated 2D driver for X11
[09:34] <persia> (as I think I argued with you many months ago, only to discover convincing you personally didn't affect the results)
[09:34] <sveinse> hehe
[09:34] <persia> Hrm?  I thought we had one of those in the archive.
[09:34] <persia> pvr-something.
[09:35] <sveinse> powervr or sgx. That a 3D accel, not 2D
[09:35] <sveinse> Thats OMAPs limitation, not Qt nor X11
[09:36] <persia> Ah, yeah.  For OMAP3 it appears there are only the EGL and GLES drivers.
[09:37] <sveinse> Anyways since you mentioned our discussion: I am going to test to run stock qt4-x11 on X in one single fullscreen Qt app to bechmark its performance vs. the direct QWS/FB implementation
[09:38] <sveinse> If it works good, we can ditch our own Qt compilation and merge over to pure native compilation
[09:38] <hrw> persia: we cannot be multiarch with cross compilation yet
[09:38] <hrw> persia: no support for multiarch headers
[09:39] <persia> hrw, Ah.  Maybe you know what sveinse needs to do to transition the dev environment to natty?
[09:39] <hrw> sveinse: you need to update your own cross compiler to handle multiarch paths
[09:42] <hrw> persia: did you saw http://jeffbastian.blogspot.com/2011/06/storage-speed-on-pandaboard-revisited.html page?
[09:42] <persia> I didn't
[09:43] <persia> Oh my.  That's a bug needs fixing.
[09:44] <ogra_> persia, well, depends which kernel he used, he doesnt give a clue
[09:45] <ogra_> i would suspect its a PM issue
[09:45] <ogra_> if the pinging improves speed that smewhat points to that
[09:46] <persia> ogra_, Sure.  Something to test against the kernels we have I suppose.
[09:46] <ogra_> well, i would expect that as part of GrueMaster's or janimo's spec work this cycle
[09:46] <hrw> prpplague wrote on pandaboard ML that issue happens also without smsc on board
[09:47] <hrw> yes most likely it is. i've modified a pandaboard to remove the
[09:47] <hrw> LAN9514 and wire a host port connector to the EHCI. even with the
[09:47] <hrw> LAN9514 removed i am still have similar issues. this leaves the USB
[09:47] <ogra_> i sere something similar on the ac100 ....
[09:47] <hrw>  </quote>
[09:47] <ogra_> *see
[09:47] <ogra_> and i actually suspect we have a general issue with USB speed on arm
[09:48] <persia> We've had lots of issues before with unexpectedly poor performance from USB storage.
[09:49] <ogra_> welll, i dont think its a storage prob at all
[09:49] <ogra_> i think its on a lower level
[09:50]  * persia suspects interrupt handling
[09:51] <persia> That said, it's low-level enough that I don't trust myself to guess
[09:51] <ogra_> i also think its related to the USB NIC driver segfaults we see with many differnt drivers
[09:51] <persia> And perhaps the reports of horridly distorted audio with some USB audio devices
[09:52] <ogra_> since it seems the majority of USB NICs  needs vm.min_free_kbytes set to some high value to not drop packages
[09:53] <persia> That's just wrong.
[09:53] <ogra_> thats the only known workaround currently
[09:53] <ogra_> i dont think anyone has tracked that bug further yet
[09:53] <persia> How does one debug this sort of thing?
[09:53] <ogra_> no idea, ask the kernel team :)
[09:54] <ogra_> likely by scattering printks all over the code
[09:54] <persia> Right.
[09:54]  * persia climbs back up the stack into code that doesn't even get compiled
[09:55] <ogra_> on the ac100 is see some funny behavior with PM and wlan ... PM powers down the card faster than a ping returns ...
[09:56] <ogra_> so you get proper throughput when you have a constant stream of data ... but if you ping you get like 3-5sec return times
[09:56] <ogra_> (when pinging without traffic in the card)
[10:02] <sveinse> I'm trying to use arm-linux-gnueabi-gcc without sysroot (since it does not support it). How do you prevent arm-linux-gnueabi-gcc to attempt to link with host libs?
[10:03] <sveinse> It tries to load: "opened script file /usr/lib/x86_64-linux-gnu/libz.so" which is not correct
[10:07] <ogra_> hey, but its 64bit, probably makes your binaries run faster on arm then :P
[10:07] <sveinse> The armel-cross ld shouldn't be searching /usr/lib and /lib, should it ?
[10:07] <sveinse> :P
[10:08] <ogra_> no idea, i dont touch cross stuff
[10:08] <sveinse> hrw ^^
[10:21] <sveinse> doing arm-linux-gnueabi-gcc -v ... reveals:
[10:22] <sveinse> LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/:/usr/lib/gcc/arm-linux-gnueabi/4.5.2/../../../../arm-linux-gnueabi/lib/:/usr/lib/x86_64-linux-gnu/
[10:22] <sveinse> I don't see why the latter is present
[10:22] <hrw> sveinse: and ' --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib' is shown too
[10:23] <hrw> sveinse: here arm-linux-gnueabi-gcc -v does not show LIBRARY_PATH
[10:24] <hrw> sveinse: http://pastebin.com/vmHmg8t6
[10:24] <sveinse> I think you need it in a complete line where it tries to link
[10:25] <sveinse> Try this: arm-linux-gnueabi-gcc -Wl,--no-undefined -Wl,-e,qt_core_boilerplate -Wl,-O1 -shared -Wl,-soname,libQtCore.so.4 -o libQtCore.so.4.7.2 -lpthread -lz -lm -ldl -lrt -v
[10:25] <sveinse> Its does nothing, but it reveals the settings
[10:27] <sveinse> FYI this is arm-linux-gnueabi-gcc 4.5.2 from natty stock
[10:28] <sveinse> hrw, 4.5.2-8ubunutu3 to be more specific
[10:35] <hrw> thx - it really looks strange
[11:36] <sveinse> hrw, why was --sysroot removed from the toolchain? Isn't it just about not using --sysroot and then it behaves equal to ld without sysroot support?
[11:41] <sveinse> Because when cross building (non debian source), if ld encounters a linker script with say "GROUP ( /lib/arm-linux-gnueabi/libphread.so.0)", using --sysroot would make ld prefix that path with a dir, while it's rather cumbersome without sysroot because I have to alter the linkerscripts.
[11:42] <sveinse> Alternatively, does ubuntu have some chroot tool/environment to do cross building in?
[11:42] <hrw> sveinse: iirc I already wrote why in your bug report
[11:42] <ogra_> sveinse, qemu-debootstrap
[11:44] <sveinse> hrw, no offence but this means that there is no will to resolve the issue and make sysroot available. With other words: I don't understand why the cross toolchain is broken by a setting which can be omitted.
[11:46] <hrw> sveinse: Linaro will provide binary toolchain which will be sysrooted
[11:47] <hrw> Ubuntu cross compilers will still be like they are cause they are more targetted as helping tool for those who want to cross compile for ubuntu then as cross compiler for embedded target developers (like in your use case)
[11:47] <sveinse> do you know if there exists a pre-build PPA for that?
[11:47] <hrw> no ppa - it will be tarballs not packages
[11:47] <sveinse> ok
[11:47] <hrw> I can send you link when will produce first working one
[11:47] <sveinse> excellent!
[11:48] <hrw> but hope that will get sane suggestions/opinions ;D
[11:49] <sveinse> yes, you'll have to excuse my naive questions, I'm just sitting here with a system which does not work.
[11:50] <sveinse> And yes, I hoped the armel-cross were a cross tool similar to codesourcery, but apparently not
[11:50] <sveinse> even though I dont think it's far off being one
[11:51] <sveinse> As a tempoarary workaround (today) I can either create a small tool which will search for all linker-script in my rootfs and replace it with the host path
[11:52] <sveinse> Or, perhaps as ogra_ suggest qemu-debootstrap, but I'm not sure how to use it though
[11:52] <ogra_> like debootstrap
[11:52] <ogra_> behaves the same from a user POV
[11:53] <sveinse> so you can run arbitrary command inside a chroot?
[11:54] <ogra_> you can run a full arm userspace in a chroot
[11:54] <sveinse> Using host executables (and not binfmt/qmeu)?
[11:54] <ogra_> no
[11:54] <ogra_> it indeed uses binfmt
[11:55] <sveinse> So compiling qt will be much slower then
[11:55] <hrw> sveinse: http://home.haerwu.biz/~hrw/t/ is my experimental one - no warranty that works
[11:56] <ogra_> will be faster than in a qemu VM but yeah, slower than cross
[11:56] <sveinse> hrw, thanks I'll try
[11:59] <hrw> sveinse: fetch and ping me - I will remove tarballs
[12:01] <sveinse> You know, I actually planned on blogging how we did our setup to make a working cross build environment. But I'm uncertain if there are interest for such a blog because we're using all the tools which is not recommended or "you're on your own"... We use rootstock to create a rootfs-dev/ dir where all -dev packages are installed. And then we used to do gcc --sysroot to that rootfs-dev/ to...
[12:01] <sveinse> ...cross build apps.
[12:01] <sveinse> hrw, eta. 4mins or so
[12:04] <sveinse> I do understand cross building is not the way ubuntu does it or wants to do it, but it's not more dirty to cross build than any other method. Apparently a bit more cumbersome obviously.
[12:06] <sveinse> hrw, done, thanks
[12:06] <hrw> thx. dropped
[12:06] <hrw> sveinse: write a post
[12:07] <sveinse> any ideas of a site where I can blog?
[12:15] <hrw> create own on on wordpress.com?
[12:19] <sveinse> hrw, cc1plus seems to depend on a set of libs. e.g. libgmp.so.10 is missing from my system (and I cant find it on packages.ubuntu.com)
[12:20] <hrw> sveinse: what is your system?
[12:20] <sveinse> Strange... ldd sais something else...
[12:20] <sveinse> amd64, natty
[12:21] <hrw> should work under natty. I built under oneiric
[12:22] <sveinse> I can try, and ignore the warning.
[12:32] <sveinse> It seems to fail because of this missing so. At least it does not give any other indication why it fails
[12:33] <sveinse> hrw, http://pastebin.com/1cqLSe85
[12:33] <sveinse> this is from a configure test within qt in our build setup
[12:39] <hrw> natty has libgmp.so.3
[12:39] <hrw> try in oneiric chroot
[12:43] <hrw> once I will get it into buildable state I will do build under natty or maybe even lucid
[13:35] <ericm|ubuntu> ppisati, ping
[13:35] <ppisati> ericm|ubuntu: pong
[15:27] <ogra_> GrueMaster, do you happen to have an up to date netbook/desktop image around on a panda or so ?
[15:28] <GrueMaster> Not atm, but I can image one and do stuff very quickly.
[15:29]  * ogra_ would like to know if Bug 794938 happens on panda too
[15:29] <ubot2> Launchpad bug 794938 in lightdm "lightdm dies with "Failed to fork: Cannot allocate memory" on login" [High,New] https://launchpad.net/bugs/794938
[15:29] <ogra_> since thats our default login manager since a few days, it would be good if it worked ;)
[15:29] <ogra_> which reminds me ...
[15:30]  * ogra_ looks what it takes to switch to the desktop seed, i should do that now
[15:30] <GrueMaster> let me know what the new name will be.  I am also mirroring the kubuntu stuff and want to make sure of no filename conflicts.
[15:31] <ogra_> i hope it will be the same as the main x86 image with just preinstalled added and armel as subarch
[15:31] <ogra_> we'll see what comes out at the rear end i guess :)
[15:31] <GrueMaster> That's the same name as the kubuntu files.
[15:32] <GrueMaster> I wish there was a way to differentiate.  Would make my life easier.
[15:32] <GrueMaster> Guess I'll have to modify my mirror script again.
[15:33]  * GrueMaster checks to see if the coffee is ready.
[15:33] <ogra_> well, ideally we would have the same name just different subarch
[15:33] <ogra_> but we dont do isos and we're preinstalled
[15:36] <GrueMaster> oneiric-preinstalled-desktop-armel+omap4.img.gz is the name of the kubuntu image.
[15:38] <ogra_> well, i just fired off a build
[15:38] <ogra_> lets see if we're lucky and the archive is in sync :)
[15:38] <ogra_> if so, we'll see what comes out :)
[15:39] <ogra_> i'm curious where it will be published :)
[15:43] <janimo> hrw, thanks for the storage speed on panda link, checking it now
[15:43] <hrw> np
[15:54] <janimo> hrw, although it indeed looks a board specific issue and not something to take into account in our storage speedup blueprint which si SD centric anyway
[15:55] <hrw> SD should die
[15:56] <hrw> 0.5$ sd card reader can get better results from simple tests then omap4 controller sometimes
[16:00] <ogra_> hmm, seems my build will survive, its over 20min in
[16:08] <Garagoth> Hello.
[16:09] <Garagoth> I'm having problem with my Ubuntu on BeagleBoard-xM
[16:09] <Garagoth> mmcblk0: error -110 sending read/write command, response 0x0, card status 0x400e00
[16:09] <Garagoth> lots of those messages during boot
[16:25] <GrueMaster> Garagoth: What image are you using?
[16:26] <Garagoth> netinstall
[16:26] <Garagoth> it installed fine... I used it for a while...
[16:26] <Garagoth> then reboot
[16:27] <Garagoth> and it cannot boot as / cannot be mounted
[16:27] <GrueMaster> netinstall?  We don't currently have a supported netinstall.
[16:27] <Garagoth> you have...
[16:28] <GrueMaster> They are enabled and get built with the debian installer, but they are untested and buggy.
[16:28] <Jef91> Howdy folks.
[16:28] <Garagoth> http://elinux.org/BeagleBoardUbuntu#Ubuntu_11.04_.28Natty.29
[16:29] <Garagoth> netinstall image
[16:29] <Garagoth> s/image/method/
[16:32] <Garagoth> GrueMaster: So netinstall I made is not supported by any means?
[16:32] <GrueMaster> Not by Ubuntu.  We are working on it this cycle.
[16:33] <Garagoth> Ah well. 3 days of work lost.
[16:36] <Jef91> I'm following the guide here - https://wiki.ubuntu.com/ARM/RootfsFromScratch
[16:36] <Jef91> And when I try to launch the qemu I am getting kernel panic
[16:36] <Jef91> Any ideas why?
[17:01] <GrueMaster> Garagoth: Most of the files these instructions use are not even from Ubuntu.  I'm looking over the scripts now.  There is no way we can support something someone else has cobbled together.
[17:02] <GrueMaster> We do have a preinstalled image for both headless & netbook for 11.04 though.  The headless image uses the serial console to run oem-config, and you can select different tasks from it for server or desktop workloads.
[17:04] <Garagoth> GrueMaster: headless install failed for me.
[17:04] <GrueMaster> Oh?  How so?
[17:04] <GrueMaster> What rev board do you have?
[17:04] <Garagoth> I can re-try it now and then I can provide you with details.
[17:04] <Garagoth> BB-xM rev C
[17:05] <GrueMaster> There were some changes apparently.  You might need my updated x-loader/u-boot.
[17:05] <GrueMaster> Let me find the link
[17:09] <Garagoth> is x-loader/u-boot update required for headless to install?
[17:09] <Garagoth> I have Texas Instruments X-Loader 1.5.0 (Mar 29 2011 - 09:06:55)
[17:10] <GrueMaster> I'm looking.  It is bug 770679 if you want to read up on it.
[17:10] <ubot2> Launchpad bug 770679 in linux "Missing proper support for Beagle XM rev B and C" [Medium,Fix committed] https://launchpad.net/bugs/770679
[17:12] <GrueMaster> Looks like a kernel fix.
[17:12] <GrueMaster> For natty.
[17:13] <Garagoth> is it in headless image already, or should I patch it somehow?
[17:13] <GrueMaster> rsalveti: ^^^  Any hints on this?
[17:14] <Jef91> anyone know of a prebuilt kernel that works with arm qemu?
[17:14] <GrueMaster> Garagoth: If it requires adding a kernel to the image, I'll bundle it in a tarball with instructions.
[17:15] <Garagoth> Thanks.
[17:16] <Garagoth> In the meantime I will re-try with headless image
[17:16] <rsalveti> GrueMaster: just need to generate an uImage from latest kernel available at proposed
[17:16] <rsalveti> it's not going to boot for the first time
[17:17] <rsalveti> you need to replace it at the image to make it boot and then install it correctly
[17:17] <rsalveti> kind of the same issue we had in the previous cycle
[17:17] <GrueMaster> ok.  I'll pull it in on my XM and create a tarball & instructions.  Thanks.
[17:17] <rsalveti> GrueMaster: yeah, but best thing is to compile the same kernel that's available with the release, adding the important patches on top
[17:18] <rsalveti> as then we can just request the user to download the uImage
[17:18] <Garagoth> Hm. I got installer, but installer failed as it had not network. Is it likely the symptom?
[17:18] <rsalveti> instead of downloading the deb and installing it
[17:18] <rsalveti> GrueMaster: I'll generate the uImage with the same kernel version used at the release
[17:18] <rsalveti> GrueMaster: can you just get what kernel version is the one used at the released image?
[17:20] <GrueMaster> linux-image-2.6.38-8-omap 2.6.38-8.42
[17:21] <rsalveti> thanks
[17:21] <Garagoth> When booting current headless image I get: "init: ureadahead-other main process (372) terminated with status 4"
[17:21] <rsalveti> give me some minutes
[17:21] <rsalveti> that's expected
[17:21] <Garagoth> ok.
[17:23] <Garagoth> And it says: Beagle unknown 0x02
[17:25] <rsalveti> this should be fixed with the new kernel
[17:25] <rsalveti> hold some minutes and I'll have an uImage for you to test
[17:26] <Garagoth> Sure.
[17:36] <rcn-ee> Garagoth, what kernel (uname -a) where you running when you were getting flooded with -110 errors?
[17:36] <Garagoth> 2.6.39-x1
[17:37] <rcn-ee> humm, weird.. which board?
[17:37] <Garagoth> BB-xM rev C
[17:39] <Garagoth> during install those errors appeared (during boot only I think)
[17:39] <rcn-ee> very strange.. i haven't seen that yet on my xM's.. i did pushout an 2.6.39.1-x1 update a couple days ago.. if you still have the image, are you able to try it? http://rcn-ee.net/deb/natty/v2.6.39.1-x1/ (install-me.sh script)
[17:39] <Garagoth> and after reboot same errors caused / to be unable to be mounted
[17:39] <Garagoth> that image does not boot anymore
[17:40] <Garagoth> fails with message that / cannot be mounted
[17:40] <rcn-ee> Sweet, then my 2.6.38 -> to 2.6.39 broke boards.. great..
[17:41] <Garagoth> :-)
[17:41] <Garagoth> Your netinstall script was fine
[17:42] <Garagoth> everything worked except no slip kernel module
[17:42] <Garagoth> and I need it :-)
[17:42] <rcn-ee> what config do you need?
[17:43] <rcn-ee> Here's my last xm stress test: http://rcn-ee.homeip.net:81/dl/gcc/sys/dmesg-174678-2.6.39-x1-beagle-xma-512mb.log  (why i'm not getting the mmc -110 error..)
[17:43] <Garagoth> I have pair of Xbee connected over USB and I need to connect then using slip ...
[17:43] <rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/beaglexm/uImage
[17:43] <rsalveti> GrueMaster: this is the kernel  2.6.38-8.42 with the rev c patches included
[17:44] <Garagoth> Are you using own sd card? I'm using card shipped with beagle...
[17:44] <rsalveti> GrueMaster: just update the wiki doc explaining to replace the uImage from the sdcard with this one
[17:44] <rsalveti> then the first boot should be fine
[17:45] <rcn-ee> Garagoth, yeah, i thru away the ones came with the xM's.. to slow..
[17:45] <rcn-ee> (thru/burned)
[17:45] <Garagoth> rcn-ee: Hm. So maybe this is a reason... I mounted that card on my laptop, fsck'ed it.. copied it fully using dd .. no errors in process.
[17:46] <Garagoth> but on BB-xM it fails to work.
[17:46] <rsalveti> GrueMaster: the user should also replace the vmlinuz that's inside the second partition, at /boot
[17:46] <rsalveti> GrueMaster: replace it with http://people.canonical.com/~rsalveti/beaglexm/zImage
[17:46] <Garagoth> Same card works fine with Angstrom
[17:46] <rsalveti> GrueMaster: as one step from jasper is to run flash-kernel again
[17:47] <rsalveti> replacing both files should be enough to get a working system based on the released images
[17:47] <rsalveti> same procedure as we used during maverick
[17:48] <rsalveti> GrueMaster: also put a note saying the user should enable natty-proposed in case he's updating his system
[17:48] <GrueMaster> ok
[17:48] <Garagoth> rcn-ee: Also, same sd card 'looks' faster under Angstrom then under Ubuntu
[17:48] <rsalveti> as otherwise he'll get a newer kernel but not the one with the fixes
[17:48] <GrueMaster> Actually, there is no newer kernel excpet in proposed at the moment.
[17:48] <rsalveti> and that should do it
[17:48] <rsalveti> even better
[17:49] <rsalveti> thought we had Ubuntu-2.6.38-9.43
[17:49] <rcn-ee> Garagoth, yeah the mmc driver has changed a lot since 2.6.32 in Angstrom... Do you need the other 3 config's enabled http://pastebin.com/5BwQT9aN
[17:49] <GrueMaster> Haven't seen one.
[17:49] <rcn-ee> They also boot at 1Ghz..
[17:50] <GrueMaster> My xm is currently running natty headless as I am using it for usbboot testing on panda.  I have been monitoring updates.
[17:51] <Garagoth> rcn-ee: Mm. well, slip was only thing I missed so far; usb serial, fddi and pl drivers were there... does your .39 kernel and build include patches rsalveti included?
[17:51] <rsalveti> probably
[17:51] <rsalveti> as rcn-ee was the one who created the patches ;-)
[17:52] <rcn-ee> it was one of those #'s.. https://bugs.launchpad.net/bugs/770679 ;)
[17:52] <ubot2> Ubuntu bug 770679 in linux "Missing proper support for Beagle XM rev B and C" [Medium,Fix committed]
[17:52] <mattwaddel> rsalveti: rcn-ee; I've been fighting the same battles as Garagoth over the last few days and I'm curious, does u-boot need to be updated to detect bb-Xm rev C also?
[17:52] <Garagoth> rsalveti: :-)
[17:52] <rcn-ee> i thought no... but a couple android people running xM C's with old u-boot these last few days have show otherwise..
[17:53] <Garagoth> mattwaddel: I have bb-xm rev c
[17:53] <Garagoth> so yes..
[17:53] <mattwaddel> Garagoth: where did you get the updated u-boot?
[17:53] <rsalveti> mattwaddel: check bug 770679
[17:53] <ubot2> Launchpad bug 770679 in linux "Missing proper support for Beagle XM rev B and C" [Medium,Fix committed] https://launchpad.net/bugs/770679
[17:53] <rsalveti> you'll find the patches
[17:53] <rsalveti> but I don't think they are really necessary
[17:54] <mattwaddel> rsalveti: got it, thx
[17:55] <rcn-ee> Oh rsalveti, heads up a new older beagle "C5" is coming out with new memory, mlo/u-boot patches have been posted to the beagleboard group...
[17:55] <rsalveti> rcn-ee: yeah, saw that
[17:55] <rsalveti> will be integrating in the following days
[17:55] <rsalveti> but thanks for heads up
[17:55] <rcn-ee> ah okay cool.  Been updating my script to include it to..
[17:58] <GrueMaster> rsalveti: Do you have a vmlinuz for the patched kernel?
[17:58] <rsalveti> GrueMaster: grab the zImage at the same link I sent
[17:59] <GrueMaster> Ok.  I'll just rename it.  Make it less confusing for the users.
[18:02] <rsalveti> GrueMaster: would be good to rename with the correct version
[18:02] <GrueMaster> Do we care about fixing maverick?
[18:02] <rsalveti> GrueMaster: do you have in hands?
[18:03] <rsalveti> like vmlinuz-2.6.38-foobar
[18:03] <rsalveti> I can rename at my host area
[18:03] <GrueMaster> I have it now.  Am posting up to my updates directory.
[18:03] <rsalveti> ok, cool
[18:03] <rsalveti> GrueMaster: for now let's just fix natty
[18:04] <GrueMaster> ok
[18:20] <MrBIOS> re
[18:22] <Garagoth> GrueMaster: How long till new files for testing will be there? Or should I just grab what rsalveti published? (It is important as I am hungry and I wonder if I have time to go eat something before I get something to test)
[18:22] <GrueMaster> Garagoth: Done.  https://wiki.ubuntu.com/ARM/OmapNetbook
[18:23] <GrueMaster> Same instructions and files apply to headless (updating that wiki now.)
[18:27] <Garagoth> Cool, thanks.
[18:27] <Garagoth> Applying...
[18:28] <GrueMaster> Let me know if there are any issues with the kernel or my instructions.
[18:29] <Garagoth> Instructions are fine.
[18:31] <Garagoth> one more thing... netbook image does not have /boot/initrd.img-2.6.38-8-omap
[18:32] <Garagoth> but there is symlink pointing to it
[18:34] <GrueMaster> Yes, that is correct.  It is made by oem-config.
[18:37] <Garagoth> oooh. it detected network. Better.
[18:38] <Garagoth> hm, so netbook install now will give me working mouse and keyboard, right? (previously they were dead, just image on screen)
[18:40] <GrueMaster> They should if you are using the netbook image.  If you are installing from the headless image...I don't know.  May need to tweak the cmdline.
[18:41] <Garagoth> How can I convert headless to give me console? u-boot params?
[18:41] <Garagoth> & getty ?
[18:42] <GrueMaster> After running through oem-config, edit /boot/boot.script and either add console=tty0 or remove the current console==ttyO2,115200n8.  Then rerun flash-kernel & reboot.
[18:43] <Garagoth> Sounds easy. Thanks.
[18:43] <GrueMaster> (should be only one "=".  I have phat phingers)  :P
[18:43] <Garagoth> Mm, figured it out.
[18:44] <GrueMaster> If you remove the "console= " entirely, you should get a nice graphical boot screen.
[18:45] <Garagoth> Hm? But I will loose serial console, right?
[18:45] <GrueMaster> True.
[18:45] <Garagoth> Angstrom does have both, serial & X at same time.
[18:45] <Garagoth> but their ld is broken somehow.
[18:46] <GrueMaster> You can add a serial login by copying /etc/init/tty2.conf to /etc/init/ttyO2.conf and editing the file to use ttyO2 115200.
[18:47] <GrueMaster> You won't see boot messages, but you will have a serial console login.
[18:47] <Garagoth> but won't u-boot display there anyway?
[18:48] <GrueMaster> Yes, that won't change.  What you would see is u-boot log output, followed by a login screen.
[18:49] <Garagoth> Hmm. Gonna figure out how Angstrom did that... but later, for now headless is fine.
[18:50] <Garagoth> By the way, why headless install displays red screen on dvi?
[18:50] <Garagoth> bright red
[18:50] <MrBIOS> because it's written by commies
[18:51] <GrueMaster> I don't see that.
[18:52] <GrueMaster> When do you see that?
[18:52] <Garagoth> all the time
[18:52] <Garagoth> for whole install
[18:52] <Garagoth> it is now removing packages, and still bright red
[18:52] <GrueMaster> Might be due to the last minute color map changes made prior to release.
[18:53] <Garagoth> or another rev C difference?
[18:55] <mattwaddel> Garagoth: that's one of the things I'm seeing with the Linaro images also
[19:05] <persia> That's not really surprising: it's the same uboot.
[19:06] <GrueMaster> It could be that u-boot isn't recognizing the silicon and throwing up a red screen.  I noticed on the bug that there is a patch floating around upstream.  Shouldn't be critical though.
[19:10] <persia> Workaround: either initialise a framebuffer or don't attach a screen :)
[19:10] <Garagoth> :-)
[19:54] <Garagoth> um... why there is no libserial on ubuntu-arm ?
[19:54] <Garagoth> normal natty has it
[19:55] <ogra_> WOHOOOO !
[19:55] <ogra_> http://cdimage.ubuntu.com/daily-preinstalled/current/
[19:56] <ogra_> GrueMaster, looks like the name is the same as kde :/
[19:56] <GrueMaster> Pffft Figures.
[19:56]  * GrueMaster modifies scripts accordingly.
[19:57]  * ogra_ is really surprised it built
[19:57] <Garagoth> Hey, what about libserial? I kinda need it :-)
[19:57] <GrueMaster> Garagoth: apt-get install libserial?
[19:58] <GrueMaster> The headless images are very minimal.
[19:58] <ogra_> ITYM libserial0
[19:58] <Garagoth> E: Unable to locate package libserial
[19:58] <GrueMaster> ogra_: When will netbook disappear?
[19:58] <Garagoth> E: Unable to locate package libserial0
[19:59] <GrueMaster> Garagoth: make sure universe is enabled.
[19:59] <ogra_> GrueMaster, after i changed the crontab (which i'll do after the call)
[19:59] <Garagoth> libserial-dev is also non-present for arm
[19:59] <Garagoth> hmm
[19:59]  * ogra_ sees it 
[19:59] <GrueMaster> Garagoth: libserial0
[20:00] <Garagoth> universe you say....
[20:00] <GrueMaster> yep.
[20:00] <GrueMaster> pool/universe/libs/libserial/libserial0_0.6.0~rc1-0ubuntu2_armel.deb
[20:03] <Garagoth> My fault for not checking this... I assumed that repo config is same as for desktops
[20:03] <GrueMaster> It "should" be.  Thought we had that fixed.
[20:03] <GrueMaster> grmbl.
[20:04] <ogra_> we did
[20:04] <ogra_> what image is that ?
[20:04] <Garagoth> ubuntu-11.04-preinstalled-headless-armel+omap.img
[20:04] <ogra_> hmm, that should definitely enable universe in your sources.list
[20:05] <Garagoth> only restricted was uncommented
[20:05] <ogra_> hmpf
[20:09] <ogra_> oh, wow
[20:09] <ogra_> the first upload of linux 3.0
[20:09] <ogra_> that was quick
[20:23] <Garagoth> netbook image also has only restricted sources enabled.
[20:26] <rsalveti> Garagoth: did the image work for you?
[20:27] <Garagoth> I just installed it. A second please, I will reboot it now to verify.
[20:28] <Garagoth> it still says: "Beagle unknown 0x02"
[20:29] <Garagoth> uhm...
[20:29] <Garagoth> ALERT!  /dev/disk/by-uuid/b1971b59-d07f-4f96-9478-4c96a43e1e56 does not exist.  Dropping to a shell!
[20:29] <rsalveti> that's weird, same happened with Matt_O
[20:29] <Matt_O> eh?
[20:29] <rsalveti> first time he tried it showed unknown, then after a reboot it showed rev C
[20:31] <Garagoth> well... I still see unknown 0x02... and root device is not found
[20:31] <Garagoth> initramfs shell
[20:31] <Garagoth> from busybox
[20:31] <Garagoth> and that is all I have now...
[20:33] <Garagoth> but dmesg shows: mmcblk0: p1 p2
[20:34] <Garagoth> Hm! it has dirrefent uuid ...
[20:38] <Garagoth> Hm, no editor in initramfs / ash ?
[20:39] <Martyn> not usually
[20:39] <Martyn> but you can do the usual "dumb" editor
[20:39] <Martyn> echo > file
[20:39] <Martyn> echo >> file
[20:39] <Martyn> ad nauseum
[20:39] <Garagoth> I use cat | sed
[20:39] <Martyn> no sed
[20:39] <Garagoth> :D
[20:39] <Garagoth> yes sed
[20:40] <Martyn> is there sed in that busybox?
[20:40] <Martyn> or initramfs?
[20:40] <Garagoth> yes
[20:40] <Garagoth> and awk
[20:40] <Martyn> yeah, then cat | sed
[20:40] <Garagoth> ash
[20:40] <Martyn> I thought that they still had some nano/pico or vi in there
[20:40] <Martyn> it's gone?
[20:41] <Martyn> cause it was the most useful thing in there, for interactive editing
[20:41] <Garagoth> so it seems
[20:41] <Martyn> damn
[20:41] <Martyn> That's unfun
[20:41]  * Martyn checks on his Versatile Express
[20:41] <Martyn> I'll be sporked .. yeah .. no vi, no pico
[20:43] <Garagoth> hm... where does that path exist?
[20:43] <Garagoth> I corrected fstab
[20:43] <Garagoth> where else?
[20:44] <Garagoth> ahm. initramfs
[20:46] <Garagoth> how can I edit this?
[21:02] <Garagoth> I have a request... please include nano and flash-kernel into initramfs
[21:02] <ogra_> why ?
[21:02] <ogra_> its on the rootfs
[21:02] <ogra_> just chroot into it
[21:02] <Garagoth> chroot... and remount /proc and /dev
[21:02] <Garagoth> into chroot
[21:02] <ogra_> mount --bind /dev /root/dev ...
[21:03] <ogra_> before chrooting
[21:03] <Garagoth> Mm.
[21:03] <ogra_> then mount sys and proc if you are inside
[21:03] <Garagoth> Ok. You are right...
[21:05] <Garagoth> rsalveti: Ok. System went up after fixing boot.script & flash-kernel
[21:05] <rsalveti> cool
[21:05] <Garagoth> for rome reason there was wrong uuid
[21:05] <Garagoth> for root device
[21:06] <Garagoth> and not whong as a typa.. entirely wrong
[21:06] <Garagoth> typo*
[21:08] <Garagoth> is mpurate in boot.script a cpu speed?
[21:08] <ogra_> yes
[21:08] <Garagoth> it is set to 500... as I have bb-xm, can I change it to 800 or 1000 ?
[21:09] <rsalveti> 800 is the maximum recommended
[21:09] <ogra_> i think 900 is max with that kernel
[21:09] <ogra_> and 800 the max recommended ;)
[21:09] <Martyn> Stick to 800
[21:09] <Martyn> you don't want all the heat that you get at 900
[21:09] <Martyn> (power consumption is a nasty, power function curve)
[21:09] <Garagoth> I do not care about power consumption
[21:10] <Garagoth> I have attached to beagle 2 microframe motors, each consuming 15 Amps @ 24 V
[21:10] <rsalveti> you can also get some weird errors with 900mhz
[21:10] <ogra_> yes, it can cost stability
[21:11] <Garagoth> So advertised 1GHz is a myth?
[21:11] <Martyn> No, it's just high sort
[21:12] <rsalveti> no, lack proper software support
[21:12] <Martyn> I have an i.mx53 running at 1Ghz .. it's hot, and it's not entirely stable, but with a heatsink it does stabilize and works well
[21:12] <Garagoth> Hm, so heatsink would be a solution you say... and what does mpurate=auto do?
[21:12] <Martyn> lets it float
[21:13] <Garagoth> from to where?
[21:13] <Martyn> dunno .. I'd have to dig around the kernel code :)
[21:13] <rsalveti> Garagoth: bug 771537
[21:13] <ubot2> Launchpad bug 771537 in linux "mpurate=1000 fails on beagleXM" [Medium,In progress] https://launchpad.net/bugs/771537
[21:15] <Martyn> between 500 and 700
[21:15] <Garagoth> Smart reflex?
[21:15] <Garagoth> Martyn: thanks. I will set 800 then...
[21:16] <rsalveti> Garagoth: dynamic voltage and frequency support
[21:16] <rsalveti> http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12032&contentId=4609
[21:17] <Garagoth> Yeah, found the same link... had no idea that linux has this...
[21:18] <Garagoth> I assumed it is a hardware solution, not software...
[21:19] <rsalveti> you also need support at the software side
[21:35] <Garagoth> mpurate is 800... what about core clock? (332)
[21:39] <ogra_> Martyn, the PXE code ...
[21:39] <ogra_> Martyn, does that send any identifier to the DHCP server during the communication so we can make out what device sent the request ?
[21:40] <Martyn> yes
[21:40] <Martyn> although I don't have the code in front of me
[21:40] <Martyn> best person to ask is Jason -- jason.hobbs@calxeda.com
[21:40] <ogra_> i.e.a vendor-class identifier or some such
[21:41] <jhobbs> yea
[21:41] <ogra_> how does it set that ?
[21:41] <ogra_> based on the board name ?
[21:41] <jhobbs> yes
[21:41] <jhobbs> CONFIG_BOOTP_VCI_STRING
[21:41] <ogra_> awesome
[21:42] <jhobbs> for versatile express: U-boot.ca9x4_ct_vxp
[21:42] <Martyn> thanks :) I knew you were online :)
[21:42] <Martyn> I just wasn't sure if you were watching IRC :)
[21:43] <jhobbs> there's also a client architecture field that can be used, it's stuff like "x86_32" or "x86_64" usually, but doesn't have official definitions for ARM parts
[21:44] <ogra_> yeah, that doesnt help our usecase ... but a vendor-class-identifier will
[21:44] <ogra_> we need to know the subarch, not the arch :)
[22:58] <MrCurious_>  gruemaster: if i install a headless image, there is no reason that i cant have it upgrade the packages to be an image with display, but after the initial install right?
[22:58] <MrCurious_> as in, there is no special bit of magic outside of the package manager installed bits differentiating head and headless installs
[22:58] <GrueMaster> Just run tasksel to select what environment you want.
[23:00] <GrueMaster> The only other tidbit is you will need to edit /boot/boot.script and either delete the console= section or add console=/dev/tty0
[23:02] <MrCurious_> cool, so not involved at all