#ubuntu-arm 2009-07-13
<Barhine> whoah
<Barhine> this is a chennel
<Barhine> so how far along is ubuntu on arm?
<BitWraith> does anybody know where I can find a version of kexecboot that supports ext4? or am I going to have to install all over again because I used such a new filesystem? :-/
<dpb> That's the reason why people have usually made a separate /boot partitions with an older filesystem.
<BitWraith> dpb, you ca't do that with kexecboot, it passes its own root= option to he kernel forcing it to use the same partition the kernel image was found on
<BitWraith> supposedly they are fixing that in the latest version, but there aren't any ready-to-flash images of it yet, and I haven't figured out how t compile it myself yet
<dpb> I see.
<lool> ogra: Hmm we should be here
<ogra> heh, yeah
<ogra> hmm, identical version in debian
<ogra> thats intresting
<lool> ogra: What about the PR 10288 change?
<lool> ogra: I couldn't fetch anything newer than 3rd of July as CVS seems down for m
<lool> me
<ogra> i'm just building with that one disabled :)
<lool> Are you bisecting?
<ogra> no, i just commented out http://paste.ubuntu.com/216821/
<ogra> s/commented out/reverted
<ogra> its at the ld tests ... i'll know in 5 mins
<lool> I doubt it's that change; I'd rather suspect the testsuite
<ogra> not being brought up to date with the code you mean ?
<ogra> well, ten it should still survive this test now
<ogra> *then
<lool> The testsuite was completely rewritten
<ogra> between 20090704 and 20090622 ?
<lool> Yes
<ogra> i only see two changelog entries
<ogra> +	* binutils-all/objcopy.exp: Move XFAIL from objcopy_test to
<ogra> +	copy_executable.
<ogra> and another unrealted one pointing to cygwin
<lool> There are multiple ChangeLog file
<lool> ogra: Did you file a bug already?
<ogra> yeah, i just see that
<ogra> nope
<lool> ogra: You might want to start there
<ogra> i was hoping to be able to attach some info
<lool> Start by filing the bug, then collect more info?
<ogra> well, the build is near the point of failure ... i'll file after it failed or passed that
<ogra> ok, failed
 * ogra files ...
<ogra> oh
 * ogra looks at http://sourceware.org/ml/binutils/2009-06/msg00289.html
<ogra> lool, bug 398732
<ubot4> Launchpad bug 398732 in binutils "binutils on armel fails to build due to regression test failure on 64 Bytes alignment test for gas/arm/arm.exp" [High,New] https://launchpad.net/bugs/398732
<ogra> feel free to mark it critical if you think its worth it
<lool> Thanks
<lool> ogra: I was thinking of filing it upstream though
<ogra> i want to have it at dokos attention first, i'll file an upstream one as well
<ogra> sigh, indeed upstream bugzilla needs a new account
 * ogra hates that
<neure> hello
<neure> anyone got kernel config for qemu?
<ogra> the linux-image for versatile package contains the qemu config we use
<ogra> lool, wow, upstream is quick :) already confirmed
<lool> ogra: Where is that confirmed?
<ogra> in the LP bugwatch
<lool> That seems broken, I see no activity in the upstream bug
<ogra> yeah, weird
<ogra> lool, btw, are you using the packaged kernel in your cloud builder or a self rolled one (and did your chnages get included in our tree already) ?
<lool> ogra: You mean the qemu kernel?
<ogra> i'd like to switch rootstock to using the packaged version and new qemu
<ogra> so i have a VM matching the HW we support
<lool> I will probably use a custom kernel and qemu, but the Ubuntu ones are good enough for now
<ogra> well, i dont want to have to change twice if we switch to v6
<lool> ogra: We don't have a versatile flavour in karmic anymore
<ogra> ugh
<ogra> ok
<lool> The problem is that the upstream linux doesn't support arm > v5 versatile by default
<ogra> i thought that was carried over
<lool> It was dropped along the "drop all the v5 stuff" commit
<ogra> hrm
<ogra> we could really have kept that
<lool> I don't have time to fix the kernel build to allow both v5 and v6/v7; if you'd like to chase it, I think it's a good idea
<ogra> given that we need it back anyway
<ogra> lets see ... if we really skip A3 i migh have time for it
<lool> ../../ld/ldlang.c:1399: error: no previous prototype for ânext_matching_output_section_statementâ
<ogra> for now there are still binutils, banshee, tomboy and a bunch of specs i have to attack :)
<ogra> not to forget the ftbfs list :)
<neure> ogra, where is that image?
<ogra> in the archive
<ogra> ports.ubuntu.com
<neure> sorry looks like i dont know how to use that
<ogra> http://ports.ubuntu.com/pool/main/l/linux/linux-image-2.6.28-14-versatile_2.6.28-14.46_armel.deb
<neure> erm
<neure> package architecture (armel) does not match system (i386)
<neure> i wonder how can i get that open just to the the config file?)
<ogra> open it with file roller :)
<neure> ah
<neure> got config-2.6.28-14-versatile
<neure> is that the one you use with qemu?
<neure> can i simply use it with 2.6.30 as well?
<ogra> you probably need to make changes
<ogra> but its a good base
<neure> im having trouble getting anything into the qemu console on boot
<neure> well
<neure> i managed to build the kernel
<neure> and i get to login
<neure> but my question is: why i dont see kernel boot messages?
<ogra> you likely dont use the right console= bootoption
<neure> well
<neure> i've tried many
<ogra> console=ttyAMA0,115200n8 should be the right one looking at http://bazaar.launchpad.net/~ogra/project-rootstock/trunk/annotate/head%3A/rootstock
<neure> ive tried console=ttyAMA0
<neure> i wonder if ,115200n8 is important, but I can try
<neure> first im enabling preempting in the kernel..
<ogra> yes, it is
<neure> nope, that didnt help
<neure> oh wait
<neure> now i do gte the boot messages if i switch to ctrl-alt-3
<neure> i wonder - can I get that to the default, ctrl alt 1 console?
<lool> Rebuilding latest binutils under jaunty gives a passing testsuite, so it builds with gcc 4.3
<ogra> lool, well, given it finishes fine in debian i wouldnt have doubted that
<ogra> fsvo fine :) there are tons of error messages from gcc in their log
<lool> ogra: http://sourceware.org/ml/binutils/2009-07/msg00038.html
<lool> (thanks to doko)
<ogra> yeah
<ogra> i dont see the patch anywhere though
<ogra> ah
<ogra> found it
<ogra> http://sourceware.org/ml/binutils/2009-06/msg00289.html
<lool> That's the one you mentionned earlier
<lool> Just Matthias reported the issue already
<ogra> yep
<ogra> ok, but didnt open any bugs
<lool> For some reason I can't build that very well from tip
<lool> Hey doko
<lool> I reproduce the failure after adding the patch
<lool> doko: So you spotted the right patch, thanks1
<lool> !
<doko> lool: yes, but Daniel Gutson wasn't able to reproduce it
<ogra> doko, do you think its not gcc version related at all ? i dont see him building with 4.4
 * ogra had the impression its the combo of patch and gcc version
<lool> doko: Could you bounce me his message so that I can reply to it not breaking the thread?
<lool> doko: I'm sub-ing to the list
<doko> lool: how do you bounce from thunderbird?
 * ogra thinks TB needs a special plugin
<ogra> mail redirect plugin it seems
<lool> doko: I don't know :)
<lool> doko: forward as an attach?
<lool> doko: So shall we just push a binutils without that patch?
<lool> doko: I confirmed that this single patch is causing the regression by building tip + that patch
<doko> lool: which regression exactly do you mean?
<lool> doko: The one from the testsuite
<doko> the newly added test?
<lool> Yes
<lool> Or do you think we should fix the test ourselves?
<ogra> would be good to have a working ld :)
<ogra> one way or the other
<doko> well, that patch is a patch for as, so why is ld broken?
<lool> doko: I'm just fixing the binutils build so that we have latest binutils
<ogra> probably the ld issue i see in the upstart build is just a fallout
<doko> lool: please let my build finish
<lool> doko: Sure, so you're building a binutils without that patch?
<doko> I'm currently checking current trunk with this patch, and trying to find out why it's not seen by Daniel. plus building on Debian as well
<doko> and we did turn on ssp recently on arm as well ...
<doko> lool, ogra: please could you check if you see the ld failure with the 20090620 binutils? This one doesn't fail the test
<doko> now building the debian binutils with the align patch on unstable. it's a slow machine ...
<ogra> will doo, but it will take a while, SD filesystem on my build machine here
<lool> doko: Isn't that the one we have now?  we have 20090622
<ogra> doko, 20090620 ? 20090622 doesnt fail it either i think
<ogra> heh, snap
<lool> doko: I see you did upload a 20090620; I guess I could try that
<ogra> though 22 did build fine ...
<ogra> (but breaks in ld for the upstart build)
<ogra> so 22 either didnt have the test or passed it
<doko> lool: got it, changed objdump output, which breaks the comparision with the expected output
<lool> doko: aha
<lool> doko: But I only see it with the patch
<doko> lool: the testcase is added with the patch
<lool> doko: So I guess we should close the upstream bug and send an updated patch to Daniel Gutson?
<lool> doko: I need to reboot my B2; the upstart build hung it; I guess OOM
<doko> ouch, ok, not sure if I had something building on it
<ogra> lool, your B2 ?
<ogra> where did you get a B2 from ?
 * ogra thought we only had one left
<lool> ogra: Just like you did?!
<ogra> oh, you didnt send yours to the kernel team
 * ogra forgot
<lool>  3954 lool      20   0  135m 126m 6216 R 92.9 26.8   0:38.71 cc1
<ogra> you were hiding for so long on that spanish island that i actually forgot about yours :)
<ogra> it hangs in cc ? not in ld ?
<ogra> wow, thats weird
<lool> 16750 nih-dbus-tool/tests/test_node.c
<lool> It's just a stupidly large file
<ogra> it builds in less than 5min on x86
<ogra> the whole of upstart
<lool> But it might be using a huge amount of memory
<ogra> hmm, i didnt check that
<ogra> i think Keybuk said something about 16000 LOC
<NCommander> o___________O;
<lool> ogra: Did you sub ubuntu-armel on that upstart bug?
 * ogra thought he did
<ogra> https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/398403
<ogra> yep
<ubot4> Launchpad bug 398403 in gcc-4.4 "gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error" [High,New]
<lool> Oh good thqnks
<ogra> https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/398403/comments/1 is on a lange btw and errors out at the same point the buildd does ...
<ubot4> Launchpad bug 398403 in gcc-4.4 "gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error" [High,New]
<ogra> the confusing part was the testbuild on the other board
<ogra> which failed at totally random places
<lool> doko: Is there a bug requesting the merge of the patch which broke our binutils bug?
<doko> lool: no, binutils doesn't use issues for bug tracking. lets wait for Daniel's reply now
#ubuntu-arm 2009-07-14
<neure> hello
<neure> is someone running linux in qemu here by any chance?)
<lool> neure: We do from time to time
<lool> doko: Thanks for the upstart -fPIE hint; it's good enough for now to not build the testsuite with -fPIE on armel
<neure> do you have real hw also?
<neure> http://pastebin.com/m17a3f14e
<neure> in case someone can try
<neure> the thing just hangs in qemu :/
<neure> im trying to figure out why, but I've got no good clues yet
<lool> neure: It works on x86 and not on armel?
<lool> neure: It hangs because you still have a thread running (the forever one); it needs to leave its loop and pthread_join
<lool> Or you need to cancel it
<lool> I don't think you strictly need to join it before exiting; I guess it's like free-ing memory before exit
<neure> the thing is
<neure> pthread_create doesn't return
<neure> yes
<neure> it works on x86
<neure> and on armel.. it works if you run with gdb
<neure> without gdb pthread_create doesn't return
<lool> neure: It works for me
<lool> pthread_create...
<lool> entering forever
<lool> pthread_create done
<lool> pthread_detach...
<lool> pthread_detach done
<lool> calling pthread_detach() ok
<neure> in what system?
<lool> On an imx51 Babbage board running armel
<neure> right
<lool> (jaunty)
<neure> this seems to be qemu problem :/
<lool> neure: What output do you get under qemu?
<neure> only the first two lines
<neure> if i run with gdb, it does all, which I find a bit strange
<amitk> ogra: lool: any recipes to use the ethernet port on B2 to download kernels?
<ogra> if you still use redboot it should work through http
<ogra> our uboot-imx we'll use doesnt have networking support (though its likely faster to just cp the kernel to /boot on the SD anyway)
<amitk> ogra: I shouldn't be using redboot? u-boot port is fully working now?
<ogra> apart from networking
<amitk> ogra: i just need something faster and more reliable than xmodem
<ogra> uboot should work, but wait for NCommander to get up to confirm and being able to give you instructions
<ogra> due to the fact that i dont have a B2 anymore i cant help much
<lool> amitk: Things like:
<lool> ip_address -l 192.168.0.106 -h 192.168.0.103
<lool> load -r -v -b 0x00f00000 -m http /initrd
<lool> load -r -v -b 0x00200000 -m http /vmlinux
<lool> amitk: But this is for another board
<lool> amitk: -l is the local IP address, -h the server address
<lool> amitk: You need to load the kernel last
<lool> amitk: You can find the addresses where to load stuff with fis list
<amitk> lool: any special config for the http server?
<amitk> -h is the server IP, I assume
<lool> amitk: Well just make sure you can get stuff using just the IP address
<lool> i.e. that wget http://x.y.z.w/foo works
<lool> amitk: 14:11 < lool> amitk: -l is the local IP address, -h the server address
<lool> Yes it's only IP; there's no DNS
<amitk> ok, thanks lool
<lool> amitk: That said, I think it didn't work for me on B1 or B2 with latest redboot; perhaps you're lucky and it does; I think you might have to set the MAC address or BOOTP on startup or something like that in "fconfig", otherwise the NIC might not be initializes
<lool> *d
<neure> sigh
<lool> The ethernet driver used to be buggy with very old redboots on B1, but worked good enough for TFTP
<neure> i tried clone and it behaves exactly like pthread_create
<neure> sigh
<neure> i dont even need to create thread
<neure> just doing for(;;){} in one program totally blocks for example doing anything in the file system
<neure> even with nice -n 19
<suihkulokki> neure: what libc/userland do you have?
<neure> this is standard debian lenny
<neure> Linux debian-armel 2.6.26-1-versatile #1 Sun Mar 15 05:49:36 UTC 2009 armv5tejl GNU/Linux
<neure> seems like qemu somehow breaks the scheduler :/
<neure> i wonder if there is any way to improve it
<amitk> lool: RedBoot> ip_address
<amitk> Sorry, networking is not available.
<amitk> :-/
<neure> 2.6.26 has CFS, right?
<auntieNeo> what are the chances of an arm build of mplayer? I'm about to file a bug, but I figured I'd ask here first in case someone can give me some insight into the state of ubuntu-arm and why mplayer hasn't been built yet
<ogra> http://launchpadlibrarian.net/28458535/buildlog_ubuntu-karmic-armel.mplayer_2%3A1.0~rc3%2Bsvn20090426-1ubuntu4_FAILEDTOBUILD.txt.gz
<ogra> thats the build log
<auntieNeo> :'(
<Martyn> auntieNeo : I have a very low priority bug to fix mplayer.  It's priority 6
<Martyn> auntieNeo : Two codecs need porting, and they won't be easy to port
<auntieNeo> Martyn: mmm... alright
<ogra> auntieNeo, and indeed patches accepted (as long as they dont break mplayer on the other arches)
<ogra> :)
<auntieNeo> are they arm5 specific bugs? there's already an arm mplayer in debian...
<Martyn> ogra : JÃ¥n JÃ¸rgensen is working on fixing vlc
<Martyn> auntieNeo: the debian mplayer was fixed by cutting out code
<Martyn> it 'runs but doesn't work"
<Martyn> or doesn't fully work
<auntieNeo> :(
<Martyn> auntieNeo : VLC should work however
<ogra> beyond that we target ARMv6 in ubuntu now
<Martyn> auntieNeo : So you're not without a video player :)
<ogra> totem definately works atm
<auntieNeo> I'm an mplayer kind of guy ;P
<auntieNeo> jk
<ogra> we definately focus in getting the default desktop 100% working
<ogra> which means gstreamer and its frontends will work
<ogra> if somone fixes other stuff or sends (or points to) patches nobody will stand in the way
<Martyn> yep
<Martyn> ogra : I found bugs with vfp and numerous other kernel bugs that cause OOPS and crashes in cortex-a9
<Martyn> we've got a lot of work
<Martyn> idle_pm is also broken
<ogra> on -a9
 * ogra would be happy to have kernels for the arches we currently support first before even thinking about -a9
<Martyn> I've also asked my boss, and ARM, and Canonical to help me give you all access to the PBX-a9's
<Martyn> It's all parallel work.
<ogra> getting these to work is hard enough atm
<Martyn> I'm already doing the heavy lifting on -A9, and have the entire dist working.  I'm working on an installer
<Martyn> installing onto a USB drive doesn't yet work,and I'm working on debugging the issue
<Martyn> I mounts the root fs, but then claims that init is killed
<neure> bah who needs init anyway :D
<Martyn> considering I can't even get it to run /bin/sh ..
<Martyn> 8heh*
<Martyn> okay, off to work
<ogra> hmm, why does xplc build flawless on debian but not for us ?
<ogra> https://buildd.debian.org/fetch.cgi?pkg=xplc;ver=0.3.13-2;arch=armel;stamp=1233251415 looks fine
<ogra> http://launchpadlibrarian.net/28443749/buildlog_ubuntu-karmic-armel.xplc_0.3.13-2_FAILEDTOBUILD.txt.gz doesnt
<mcasadevall> Sarvatt, it started failing when they moved to lzma compression
<Sarvatt> that wouldnt happen to have been between 6-30 and 7-07 would it? :D
<mcasadevall> Sarvatt, sounds about right
<mcasadevall> Sarvatt, as I previous said, I setup the launchpad-buildd code so I could reproduce the full environment (I thought we had a possible hang in pkgstriptranslations)
<mcasadevall> Sarvatt, but once the build timeout was bumped long enough, I had a successful build
<mcasadevall> Sarvatt, bbiab
<Sarvatt> thanks for the info!
<ogra> we need to get you slower hardware !
<ogra> so it matches the buildds
<Sarvatt> is it me or did qemu-arm slow down 10x in the past 6 months? 5 minutes to set up openssh-server! (2.4ghz turion x2 on x64)
 * Sarvatt is scared to think how long mesa will take to build on a G1
<mcasadevall> ogra, I just had a brainwave
<ogra> OMG !
<mcasadevall> (yay for 20 minutes of doing something else to kickstart the brant)
<mcasadevall> ogra, question one, did we change GCC to use VFP this cycle?
<mcasadevall> and if 1 is yes, has lzma been rebuilt since then
<ogra> i think 1 is yes
<ogra> and i dont know about 2
<mcasadevall> ogra, of 2 is no, we might know why we're dealing with such epic slowness w/ lzma
<mcasadevall> ogra, no uploads since hardy
<mcasadevall> ogra, we *might* just have a winner
<ogra> try a no change rebiuld
<ogra> or probably forst a local one :)
<mcasadevall> ogra, I just popped on rimu to test my theory
<mcasadevall> ogra, I'll rebuild lzma, then start a build of mesa with my lzma in the PATH
<ogra> cool
<ogra> indeed that sounds like a valid theory
<mcasadevall> ogra, cold water to the brain can do that :-)
<Sarvatt>     CONFARGS += --with-arch=armv5t --with-tune=cortex-a8
<Sarvatt>     #CONFARGS += --with-float=softfp --with-fpu=vfp
<Sarvatt> ?
<mcasadevall> Hrm
<mcasadevall> That's ... odd
<Sarvatt> thats 4.4.0-8ubuntu2
<mcasadevall> I'm not sure if we're building with VFP or not now
<suihkulokki> Sarvatt: ssh-server creates a ssh server key - and that depends on available entropy
<Sarvatt> it took 5 hours to set up a build-essential seed qemu image with ogra's script :(
<Sarvatt> and it deleted it after aparently, DOH!
<ogra> it creates a tgz if you dont tell it differently
<ogra> thats its main purpose
<mcasadevall> ogra, seems my theory is a bust :-/ http://paste.ubuntu.com/218187/
<Sarvatt> yeah i used --notarball
<mcasadevall> ?
<mcasadevall> er
<mcasadevall> ogra, we're not build w/ VFP ...
<Sarvatt> sudo ./rootstock --fqdn qemu-test --login qemu --password qemupwd --notarball --imagesize 3G --seed build-essential,openssh-server
<ogra> mcasadevall, i thought we did already
<mcasadevall> ogra, doko says we're not
<ogra> oh, right, not before the new HW arrives i guess
<mcasadevall> ogra, ok, so lets see what sort of difference VFP makes
<suihkulokki> for lzma?
<mcasadevall> yeah
<suihkulokki> you don't need testing to figure that out :)
<mcasadevall> suihkulokki, well, it might determine how we can easily fix out lzma makes ARM go *splat* boom
<ogra> Sarvatt, well, that should keep an img file around
<mcasadevall> suihkulokki, -mfpu=vfp should do the trick, no?
<suihkulokki> mcasadevall: I can save your time - vfp wil have 0, nada, nil, etc difference for lzma
<mcasadevall> suihkulokki, ?
<mcasadevall> suihkulokki, why?
<Sarvatt> looks like it saved it to /tmp and got wiped on reboot, my mistake
<ogra> ouch
<ogra> it should have copied it to your current dir though
<ogra> save_qemu_img()
<ogra> {
<ogra>     cp $IMAGENAME $DIR
<ogra>     echo "I: Qemu image saved as $DIR/qemu-armel-$STAMP.img"
<ogra> }
<suihkulokki> mcasadevall: why do you think it would have any effect?
<ogra> DIR is $(pwd)
<mcasadevall> suihkulokki, I would think use of floating point operations would greatly speed up a compression engine written in C
 * ogra rushes out to the store
<Sarvatt> thats odd, it was a ntfs-3g mounted partition i did it in because i was out of space, maybe a permission problem or something
<suihkulokki> mcasadevall: why would a lossless general purpose compressor use floats?
<mcasadevall> suihkulokki, indeed. so that theory is bunk
<mcasadevall> suihkulokki, Oh well. Got any good ideas short of creating a distlzma/distlzmad ;-)
<suihkulokki> mcasadevall: I suggest reading http://tukaani.org/lzma/benchmarks and the repeating the relevant parts on arm and selecting then a lzma/gzip compression level that makes sense
<neurre> hi
<neurre> i wonder if there are prebuilt images anywhere?
<ogra> there are, for the imx51 architecture, nslu2 and qemu
<neurre> oh great
<neurre> where?
<neurre> how come i failed to find them
<ogra> http://cdimage.ubuntu.com/ports/releases/jaunty/release/
<ogra> the nslu2 one is a netboot one
<ogra> as well as the versatile
<neurre> which one is good for qemu?
<ogra> http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/current/images/
<neurre> versatile netboot?
<ogra> yep
<neurre> mm how do i start this?
<neurre> should i do something like:
<neurre> qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.28-11-versatile -initrd initrd.gz -hda arm-rootfs.img -m 256 -append "root=/dev/sda mem=256M"
<neurre> ?
<neurre> yeah
<neurre> it worked
<neurre> well at least it booted
<neurre> Installing the base system
<neurre> dumdidum
<neurre> 0%
<neurre> ..
<neurre> this is going to take a while i guess
<neurre> that Installing the base system progress bar could use some calibration :)
<neurre> but i guess those are kind of hard
<neurre> to get them right you'd need one calibration pass
<neurre> awww this is really going to take a while
<neurre> you know net installer was not exactly 'prebuilt' i had in mind
<neurre> and here i am talking to myself :D
<neurre> bae system.. 50% :)
<neurre> base
#ubuntu-arm 2009-07-15
<neurre> base system 64%
<neurre> been forever
<neurre> Configurring ca-certificates...
<neurre> doh
<neurre> still 62%
<neurre> tada
<neurre> yeah it took a while
<royu> Hi all
<royu> Can somebody tell me, please, is there some significant difference between ARM and ARMEL ?
<lool> amitk: You might have to enable stuff in fconfig to have networking available
<amitk> lool: ok
<neure> suihkulokki, ping
<ogra> https://lists.ubuntu.com/archives/ubuntu-users/2009-July/191184.html
<ogra> nice
<neure> uh
<neure> i feel like i want some arm box myself
<ogra> dont ge ARM11 though :)
<ogra> *get
<neure> what should i get?
<neure> whats the matter with arm11?
<ogra> beagleboard should be good for a start
<ogra> we will only support ARMv6/v7 in the future arm11 is ARMv5
<neure> oh
<neure> hmm
<neure> i thought qemu was only ARMv5 though?
<ogra> no, it can support cortex-a8 (ARMv7) its just that there is no kernel for it
<ogra> there is a hack for beagleboard support, google for it :)
<ogra> and there is https://lists.ubuntu.com/archives/ubuntu-mobile/2009-May/002485.html
<neure> i wonder if someone has prebuilt qemu, realview rfs also
<neure> kernel is pointed there..
<neure> erm
<neure> i trid rootfilesystemfrom scracth
<neure> well it didn't give me network in qemu :/
<ogra> during build ?
<neure> after build
<ogra> or do you mean the resultin image
<neure> resulting image
<ogra> well, you need to configure it in the image
<neure> how?
<neure> sudo ifconfig only shows lo
<ogra>  /etc/netwrok/interfaces
<ogra> ah, well, manually do the following:
<ogra> sudo ifconfig eth0 up
<ogra> sudo dhclient eth0
<ogra> if you configure it in /etc/netwrok/interfaces it will come up automatically on boot
<neure> ah
<neure> thanks
<neure> that helped
<neure> my linux skills are rusty
<neure> i tried sudo ifup eth0
<neure> it complained something funny :D
<ogra> ifup looks in /etc/network/interfaces for an entry ;)
<neure> heh
<neure> what does eth0 line there look like?
<neure> googled
<neure> openssh-server package is a bit funny
<neure> i dont understand why it needs all that libx* stuff
<neure> oh way, for X11 forwarding_
<ogra> right
<neure> maybe i should have used dropbear instead
<neure> hmm
<neure> i dont seem to be able to ssh to the qemu server though
<neure> i installed openssh-server
<neure> according to ifconfig the qemu is 10.0.2.15
<neure> but i can not connect to that from host
<ogra> yes, but thats internal
<neure> internal to.. qemu_
<neure> ?
<ogra> someone added a reciepe for setting up network forwarding to the wikipage
<neure> where is the wikipage?)
<ogra>  /topic :)
<neure> cant see :(
<neure> i mean anything about network
<neure> sorry
<neure> i was looking at the wrong page :D
<neure> erm
<neure> that bridge thing didnt quite work
<neure> sudo ifup br0
<neure> add bridge failed: Package not installed
<neure> and more
<lool> Install bridge-tools
<lool> Sorry bridge-utils
<neure> ugh
<neure> i misread the instructions
<ogra> and please correct the wiki if thats not mentioned there
<neure> i was doing the host stuff inside qemu :D
<neure> my host is windows..
<ogra> tricky
 * ogra wonders if his rootstock test with cortex-a8 just hangs or is simply slow
<ogra> i probably shouldnt hide kernel messages
<neure> probably not :D
<ogra> oh ! it moved
<neure> wtf
<neure> i right client on bat file to edit the script to lauch qemu and windows claims that "Open File - Security Warning. The publisher could not be verified. Are you sure you want to run this software? Name: ubuntu_run.bat ..."
<neure> ah that was because i edited the file on network drive :D
<neure> wrong one
<rjune_wrk> !o
<ubot4> Factoid 'o' not found
<rjune_wrk> oh yeah, wrong room
<rjune_wrk> ogra!
<ogra> heh
<rjune_wrk> HOw goes it?
<ogra> busy working on rootstock
<neure> oh well
<neure> i can use -redir to get ssh connection to host
<neure> hmm
<neure> is it normal to get packages cannot be authenticated error?
<neure> gdb causes at least
 * ogra grins ... i just googled for project rootstock ... second hit after the LP page: "PROJECT: Rootstock Effects on Mango Productivity"
<ogra> neure, sudo apt-get update
<ogra> your packagelist in the image is likely outdated
<neure> funny i thought i already did apt-get update
<neure> oh dear
<neure> i installed ubuntu arm
<neure> in qemu
<neure> i tried netinstall and rootfsfromscratch
<ogra> call it rootstock :) less typing :)
<neure> does it have a new name?)
<ogra> (and the new name for it)
<neure> :D
<neure> well the thing is.. qemu doesnt multithread very well :/
<neure> same issue with all linux i've tried so far.. if i create a new thread which busyloops like for(;;), pthread_create / clone never returns :(
<neure> in fact, the system hangs
<neure> on some setups, i can break the offending program, but on this ubuntu, i cant do anything
<ogra> well i think lool tried it yesterday and it worked on HW
<neure> yeah
<neure> so i think its some funny thing with QEMU
<neure> which is bad, because i need to get it work in QEMU
<neure> :(
<ogra> well, it might even work in qemu if its not running under windows
<ogra> who knows
<neure> i've tried that too
<ogra> ah, so you know :)
<neure> didn't work any better in linux :/
<neure> well i tried in in VMWare which was running on top of windows..
<neure> and i only used qemu-system-arm
<suihkulokki> neure: which compiler are you using to test your threading testcase?
<neure> gcc
<neure> my qemu just hang so i cant check the version
<neure> 4.3 i think
<neure> suihkulokki, i'd really like to know which kernel and rfs you are using
<suihkulokki> a gcc from the same distro?
<neure> yes
<suihkulokki> that was just debian lenny armel
<neure> i tried with debian lenny arm
<neure> i tried with debian lenny armel
<neure> i tried with ubuntu armel
<neure> with their own kernels and packages
<neure> and they all behave more or less the same
<neure> on lenny i was able to break the offending thread
<neure> and if i run with gdb, it worked
<neure> on ubuntu i only did first try with gdb
<neure> i wasnt able to break
<neure> i also tried in windows qemu, and linux qemu (althought that linux run inside vmware on top of windows)
<neure> and i have absolutely no clue what is causing this :(
<neure> and i'm running out of things to try :/
<Sarvatt_> is there a specific platform the arm port is designed around right now or is it targetting hardware that isnt out yet? wondering what options I have right now besides a beagleboard.. I'm guessing sheeva wont be supported much longer in karmic when things move up to armv6+?
<neure> Sarvatt, the targets are listed on the qemu page
<neure> oh
<neure> sorry
<neure> this is ubuntu :)
<neure> wrong #
<ogra> Sarvatt, btw, rootstock is fixed, that your image ended up in /tmp was a bug
<Sarvatt> ohh thank you ogra
<lool> mcasadevall, ogra: So on these lzma slowness thing
 * ogra is just working on cortex-a8 support for the karmic version :)
<lool> mcasadevall, ogra: Did we benchmark it/profile it?
<ogra> lool, i thought mcasadevall did
<lool> It might be that there's a bug in lzma simply; unaligned access or something
<mcasadevall> lool, it works (slowly) on my Babbage boards
<Sarvatt> heres my log if it helps anything http://sarvatt.com/downloads/rootstock-200907121533.log.txt
<mcasadevall> lool, and I fed a few test files through lzma -9 on rimu, no issue
<mcasadevall> expect speed
<lool> mcasadevall: I had in mind that perhaps lack of VFP or unaligned accesses could slow it down
<mcasadevall> lool, VFP didn't make a difference
<ogra> lool, in any case if the majority of packages makes actual use of the 10h timeout thats not feasable
<lool> mcasadevall: You rebuilt it with softfp?
<mcasadevall> lool, yeah
<mcasadevall> lool, there are no floats in the code
<lool> mcasadevall: Do you think it could be unaligned access?
<mcasadevall> lool, the buildds are set to mode 0: do nothing
<mcasadevall> unaligned access would cause a sigill
<lool> mcasadevall: Perhaps you could oprofile it?  or gprof, dunno what exposes the issue best
<lool> mcasadevall: Well that depends on the system setup AFAIK
<lool> Also v7 handles unaligned accesses
<mcasadevall> lool, the buildds are v5
<ogra> Sarvatt, oh, thats a different issue but its fixed since some days ... the reboot command was missing because new upstart didnt build
<mcasadevall> and rimu is setup the same way as the buildds
<lool> mcasadevall: Oh really?  I didn't know that  :)
<ogra> heh
<mcasadevall> lool, :-)
<lool> I wouldn't have imaginated we're running v5 buildds really  :)
<mcasadevall> Ok, stupid point
 * mcasadevall dons the dunce cap
<mcasadevall> :-P
<mcasadevall> lool, on my tests, compressing a 13MB tar file takes 48 seconds with lzma -9
<mcasadevall> But that doesn't max out the RAM
<mcasadevall> you run into problems when compressing with lzma on 512MB
<lool> Ah
<ogra> yay
<mcasadevall> lool, then the system starts paging out
<Sarvatt> can you change the compression level on an arch specific basis for dpkg-builddeb globally?
<lool> Perhaps we can configure lzma in a less expensive mode where it uses less memory?
<mcasadevall> lool, you can guess what happens next
 * ogra has a cortex-a8 build with all features we need for qemu
<mcasadevall> lool, that was is a possibility
<suihkulokki> lol, lzma -9
<mcasadevall> lool, I'm not in love w/ it though. lzma in almost any mode is going to guzzle down memory faster than anything else
<lool> mcasadevall: Could you check how much that helps and if yes how to make that the default on armel?
<lool> suihkulokki: It's to run KDE anyway    :-P
 * mcasadevall has run KDE on ARM
<mcasadevall> :-)
<Sarvatt> even just -7 would be half the memory required or less
<lool> Sarvatt: I think that's what we'd want to look into, yes
<lool> (re: compression level in dpkg-bd)
<ogra> hmm, i thought i saw an rtc patch in lool's patchset ... weird
 * mcasadevall grabs dpkg's source
<lool> I don't see any flag passed to lzma by dpkg-dev stuff though
<suihkulokki> lzma -9 gives, what, 1% size reduction over lzma -5ish and takes twice as long and multiple times the ram
 * mcasadevall is looking now at the dpkg-deb code
<lool> ogra: Just enabling the RTC kernel CONFIG_ I guess?
<ogra> lool, yeah
<ogra> but it doesnt seem to work, it moans on shutdown
<ogra> but ...
<ogra> cat /proc/cpuinfo |grep Processor
<ogra> Processor	: ARMv7 Processor rev 0 (v7l)
<ogra> :D
 * ogra hugs qemu
 * neure curses qemu
<ogra> inotify and tcp.syncookies added
<ogra> as well as sysfs deprecated dropped
<neure> apparently it messes up guest scheduling when run in windows :(
<neure> due to crappy timers
<lool> The default compression in lzma is 7
<mcasadevall> lool, and that's what we use
<mcasadevall> we don't pass -9 on lzma
 * mcasadevall just checked the source
<lool> mcasadevall: I just said that earlier
<mcasadevall> oh
<lool> mcasadevall: Could you see what lzma level is acceptable on 512m of RAM?
<mcasadevall> TBH, I would consider not using lzma at all on that little RAM
<ogra> -0 :)
<lool> mcasadevall: Well I find it a bit ugly to patch a bunch of patches not to use lzma, or to patch dpkg-dev to map lzma to something else
<lool> While I find it decent to set the default lzma level in dpkg-dev or in lzma itself to something reasonnable depending on the arch
<lool> s/a bunch of patches/a bunch of packages
<mcasadevall> lool, well, changing the code in dpkg to remap lzma to bz2 looks simple enough. Its a case switch that needs to be conditionally overridden
<mcasadevall> I'll see on RAM usage
<suihkulokki> forget bz2
<mcasadevall> suihkulokki, ?
<lool> mcasadevall: I find it ugly really
<lool> dh_foo --I-want-lzma => you get something else; that's a nono
<lool> --I-want-lzma-but-I-dont-care-which-compression-pick-it-for-me sounds nicer
<suihkulokki> mcasadevall: among other things, it's slower to decompress than lzma
<mcasadevall> suihkulokki, its not to bad on +1Ghz boards
<mcasadevall> suihkulokki, and decompression isn't quite so RAM hungry
<suihkulokki> ...
<mcasadevall> lool, well, the other idea I had, depending on how crazy I am, is we could write a distlzma-like program and offload the compression :-)
<mcasadevall> (probably not something we want to do, but worth throwing the idea around before its shot down)
<lool> mcasadevall: Situation at hand: packages FTBFS due to a timeout; we don't care about the packages being compressed (we don't use -dbg)
<mcasadevall> lool, I get the point
<suihkulokki> mcasadevall: did you read the benchmark link I gave you yesterday?
<lool> So I think a light touch and simple change is a better choice than inventing a new tool, integrating it etc.
<mcasadevall> suihkulokki, I did, but it didn't give a great overview of RAM usage per notch
 * lool loads http://tukaani.org/lzma/benchmarks
<mcasadevall> er
<mcasadevall> wait
<mcasadevall> sorry
<mcasadevall> Wrong benchmark
 * mcasadevall had a bunch of google links open to this
<lool> suihkulokki: The page underlines the relatively low gain in compression ratio of using higher lzma modes but the high cost in memory
<lool> So I think it kind of speaks for changing the default mode of lzma or the default lzma mode which dpkg-dev uses
<lool> suihkulokki: Don't you have issues building KDE packages in Debian as a result of this?
<suihkulokki> lool: I don't think we've gone lzma
<mcasadevall> the lzma change is only because we can't fit KDE4 on the CD anymore
<mcasadevall> *sigh*
<lool> mcasadevall: So it's 100% Ubuntu specific?
<mcasadevall> lool, at the moment, I'm not sure if pkg-kde plans to adapt it or not
<lool> I find it ugly, but it's the KDE folks' decision
<lool> mcasadevall: So are we in agreement over the proposed changes?
<ogra> lool, mesa seems to use lzma for dbgsym or dbg packages
 * ogra isnt sure which
<lool> ogra: -dbg
<ogra> right it was one of the two
<mcasadevall> ogra, I think they simply set the dpkg-deb line to build all of them as lzma, and the -dbg just gets compressed. I'm not even sure if you can set per-packaging compression options with the standard rules foo
<suihkulokki> even lzma -2/-3 beat bzip2 -9 ratios and doesn't really use much more ram (and compressess faster)
<mcasadevall> lool, just a matter of determing which -X option we want
<ogra> i think thats the only other package with probs currently on the ftbfs list
<ogra> (which doesnt mean there arent others)
<lool> mcasadevall: So you agree we should just change the default compression ratio on armel somewhere?
<ogra> mcasadevall, but other packages arent that huge
<mcasadevall> ogra, when you fighting for every kilobyte on the CD, it makes the difference
<suihkulokki> ofcourse, to be systematic, one would measure the different levels directly with the problematic -dbg package and pick a level that gives the best compression ratio/ram usage ratio
<mcasadevall> lool, best cost/effort ratio I can see
<mcasadevall> lool, we're not as concerned with the image size as everyone else since ARM is .img and not iso
<lool> mcasadevall: Could you bring this up either with dpkg or lzma upstream or both and see what they think of it?
<lool> About -dbg: sorry folks, I have been misleading: builds timeout when packing these because cdbs packs packages separately, but it's an option which is used on all .debs built by a source which is why it gives space savings on the CD and why it makes the build globally longer
<lool> It's not an option passed only to -dbg as I might have implied
<mcasadevall> lool, er, I can understand lzma upstream, but why dpkg upstream? This is a very ubuntu-specific change we're considering
<lool> mcasadevall: Don't you think dh_builddeb -Zlzma would behave equally as bad under Debian?
<Sarvatt> mesa built fine on 06-30 in 3 hours and failed to build even after 10 hours starting 07-07.. dpkg was updated between the two to 0.15.2 and they switched dpkg-builddeb to add format=gnu and drop all TAR_OPTIONS, was it using format=posix by default on arm before? thats really a long shot but it seems to me like the lzma problems started after a certain date
<mcasadevall> suihkulokki, unless you think such a change it worthwhile for debian-armel?
<mcasadevall> Sarvatt, I didn't look at mesa in depth. I saw the problem crop up w/ KDE packages at first
<lool> Sarvatt: It didn't build on 06-30?! https://launchpad.net/ubuntu/+source/mesa/7.5~rc4-1ubuntu1/+build/1100008
 * mcasadevall needs to rule something out
<Sarvatt> that was a debian/rules error tjaalton did
<Sarvatt> 1ubuntu2 built fine
<lool> Sarvatt: Indeed it built with lzma recently
<mcasadevall> O_o;
<mcasadevall> That's strange to say the least
<mcasadevall> the lzma package itself hasn't been touched since intrepid
<mcasadevall> I ruled that out
<lool> The TAR_OPTIONS removal was at my request because some users had -z exported in TAR_OPTIONS and were createing source packages with this set
<Sarvatt> the only change between 1ubuntu2 and 1ubuntu3 was a patch added that only touches the intel driver in mesa that doesnt even get built on arm
<lool> mcasadevall: Could you try downgrading dpkg-dev and see whether you get a faster lzma again?
<lool> I'm confused about the change in speed too
<mcasadevall> lool, I can't reproduce locally
<mcasadevall> lool, I setup launchpad-buildd on a Babbage board with latest chroots when this issue popped up
<mcasadevall> The package build successfully after many hours, and the recent change in KDE was lzma compression
<lool> mcasadevall: Check with mesa
<lool> mcasadevall: You have a reference speed of 3 hours in earlier versions
<mcasadevall> lool, I haven't reproduced that build failure yet though
<mcasadevall> Alright
<mcasadevall> let me start that now
<lool> Which bumps to more than 14 afterwards
<lool> Sarvatt: Good catch, thanks!
<Sarvatt> definitely looks like something in the environment that changed in that case to me
<mcasadevall> lool, my hardware it slower than the buildds, but if it hangs in the same place after ~5 or so hours, I think we can call it reproduced
<mcasadevall> If not, I think we have a bigger problem
 * ogra enables preempt for fun on his test kernel
<mcasadevall> meh
<mcasadevall> uboot fat reading is very slow
<ogra> dont use fat :)
<ogra> use ext2
<mcasadevall> how?
<ogra> no idea
<ogra> you got the hardware, i dont :)
<mcasadevall> oh bah
<mcasadevall> I gave the wrong offset
<mcasadevall> you need physical addresses in u-boot or BAD THINGS(tm) happen
<ogra> hmm, preempt seems to speed it up
 * ogra wonders what the drawback is
<ogra> lool, did you try to enable smp when you played with the v7 kernel ?
 * ogra wonders if that would be worth a try
<Sarvatt> i should have just bought a beagleboard a year ago, been holding off because its been sounding like theres going to be better released any time now since november but still cant find anything.. sheevaplug is looking alot better but i'm sure karmic will switch to armv6+ as soon as it gets here :D
<Sarvatt> i thought jaunty was going to be armv7 from the start going by the press releases
<ogra> we tried to keep jaunty close to debian
<ogra> since it was our first release and v7 hardware is rare
<ogra> at least the v7 HW we support
 * mcasadevall would love to know why u-boot takes 30 seconds to load a kernel image
<Sarvatt> my efika is begging to be upgraded with something arm :)
<ogra> hrm
<ogra> why does /etc/init.d/sendsigs not finish
<dirk2> I used ARM/RootfsFromScratch from https://wiki.ubuntu.com/ARM to create a rootfs. If I understood correctly, this takes the pre-build binary packages and creates the rootfs from it. Now I wonder how are the armel binary packages created from source? That is, how is Uuntu ARM cross compilation done?
<ogra> not at all :)
<ogra> the packages are all build natively
<dirk2> orga: Native compile?
<ogra> https://launchpad.net/builders
<ogra> there are three armel build machines at the bottom
<dirk2> ah, I see. Any info what hardware is behind this?
<ogra> some 800MHz 512M boards
<ogra> i dont know the exact SoC names
<dirk2> uuuhi, ARM @ 800MHz
<ogra> yeah :)
<ogra> well thats the avreage HW we also target with the distro build
<ogra> *average
<dirk2> Is it possible for a user (e.g. me ;) ) to use these machines to compile something?
<ogra> no, sadly not, there is work going on to set up a cloud based buildsystem though
<ogra> but that will use qemu
<ogra> and should make PPAs possible
<ogra> or something similar to PPAs
<dirk2> sometihng like OpenSuseBuild System for ARM?
<ogra> something like that, yes
<dirk2> sorry, PPA?
<ogra> well, and indeed you can upload packages to ubuntu if you like ... through REVU and sponsoring
<dirk2> ok ;)
<ogra> https://help.launchpad.net/Packaging/PPA
<dirk2> ok, thanks
<rjune_wrk> ogra: are you around?
<NCommander> lool, so if this test passes, what is our next step?
<NCommander> (I had a previous pass with some the KDE packages, so I'm leaning that this will pass too)
<lool> NCommander: Which test?
<lool> :-P
<lool> ogra: We don't have SMP support in emulated qemu boards
<lool> ogra: But yes, I did try this out
<lool> Actually I tried the v6 realview SMP one
<lool> But realview is in a poor state of emulation/upstream support in that there's no PCI support in upstream linux and qemu expects one and actually needs one to offer network and SCSI hard disk...
<NCommander> lool, building mesa w/ the launchpad-buildd setup
<lool> NCommander: Well if it's fast, we need to find out why it's not on the buildds; with IS probably
<lool> NCommander: But I would expect it's slow and we need to find which package changed (e.g. try downgrading dpkg-dev)
<ogra> lool, yeah, i found that out myself ... would also need kernel hacking, SMP is no option with versatile
<ogra> rjune_wrk, whats up ?
 * ogra has to go in 5 min, if its important, shot now or never
<rjune_wrk> ogra: can I get you to try something for me?
<ogra> *shoot even
#ubuntu-arm 2009-07-16
<mcasadevall> lool, mesa built successfully in launchpad-buildd on babbage 2
<mcasadevall> lool, I believe I can officially say argh
<Sarvatt> 10 hours mcasadevall?
<mcasadevall> Build needed 03:44:36, 1393092k disk space
<mcasadevall> Nope
<mcasadevall> SOmething has got seriously wrong on the actual buildds ...
<Sarvatt> ahh was like 12:30 my time when we were talking about it so thought it might have actually taken the 10+ hours
<lool> mcasadevall: Could you bring this up with IS?
<ogra> hmm, doesnt look if i gained much with more ram for debootstraps second stage ... its simply the lack of CPU making it slow
<ogra> hmm, ok, the unpacking surely is faster
<ogra> wow, locale-gen is gotten a lot faster
<ogra> real	51m49.350s
<ogra> user	48m31.682s
<ogra> sys	0m21.285s
<ogra> not to bad for an ubuntu-minimal
 * ogra comments all the swap stuff and runs it again
<ogra> real	51m9.016s
<ogra> user	47m42.963s
<ogra> sys	0m22.133s
<ogra> hmm, no significant difference
<ogra> so guess i'll leave the swap part in but dont add the ugly bits that make it be used *before* debootstrap runs
<ogra> since that requires to unpack busybox-static in the choot before switching to VM to have swapon available before a system exists
<ogra> meh /me wants a --to-the-rim option for dd so it only fills a file up to the max available space on the target device
<lool> ogra: What's the status of the banshee bug?
<ogra> dyfet, is looking into it atm
<lool> ogra: Why are you assigned?
<lool> dyfet: hey what's the status of the banshee bug?
<ogra> should i reassign ?
<lool> ogra: What do you think?
<ogra> well, i felt responsible for it even though dyfet looks into it atm
<lool> ogra: If you're responsible for it, could you please give me a more detailed status update?  There's nothing in the bug
<lool> I don't know what's being investigated, what are the current results etc.
<lool> The fact that dyfet is looking into it is mentionned nowhere
<ogra> well, i asked dyfet to take a look and pointed him to the vorbis error
<lool> ogra: When was that?
<lool> ogra: Could you please document that in the bug itself?
<ogra> that was two days ago, i'll add info to the bug
<lool> ogra: Thanks
<lool> ogra: What about the debian-cd specs (subarches and mx51 changes); will this happen for Alpha 3?
<ogra> i'd really like to have a prototype but without the HW its not that easy to work out a uboot layout
<lool> ogra: Did you test Uboot on the lange?
<lool> ogra: I don't think the subarch changes need any hardware though
<lool> ogra: Are the Uboot packages ready?
<ogra> i tested the binary image we had
<ogra> but that didnt work
<lool> Ok
<ogra> was waiting until NCommander has his binary through NEW
<lool> So it's in NEW? good
<ogra> he told me tue. its sitting there
<lool> ogra: So what about the armel -> armel+mx51 changes?
 * ogra sighs ... calling cleanup on 0 1 2 3 9 11 13 15 has intresting sideeffects
<ogra> lool, i want to have uboot-install separately
<lool> Yes?
<ogra> so i'm blocking on the layout as i mentioned above
<lool> Well you could rename the script first
<lool> That makes room for the Marvell stuff in parallel
<ogra> grmbl, why is cleanup called multiple times now
<ogra> lool, ok, i'll do the renaming this week
<lool> Ok thanks
 * ogra slaps forhead
 * ogra removes "exit 0" from the end of cleanup() and goes to a corner to cry
<ogra> grmbl now it doesnt exit properly
 * ogra curses, it was all working before
 * ogra re-adds the cleanup acll at the end of the script 
<ogra> trapping on 0 is simeply not working right
<kod-e> hi all
<lool> dyfet: Hey when you come up, could you update the banshee bug with your findings?
<lool> ogra: trap 0 works fine for me   :-)
<dyfet> lool: yes...but I dont have update yet...I was fighting hw part of yesterday to get karmic setup on it :)
<ogra> lool, i have massive probs with all the traps here
<ogra> if i trap out of run_vm it essentially does nothing
<ogra> well, it prints the "Cleaning up..." but exists immediately
<ogra> everywhere else trapping works fine
<ogra> well, thats not actually right, trapping works in run_vm if the vm actually runs but not while wget runs or the vm is just starting up
<Sarvatt> so is marvell support going to be kept in karmic?
<ogra> kept ?
<ogra> its being added
<Sarvatt> ah, new kernel flavor? i just meant the armv5, didn't know if it was going to go v6 or v7 only during karmic
<ogra> it will be v6
<Sarvatt> oh wow, i should have read up more on sheeva
<lool> Sarvatt: Right, Sheeva wont work
<lool> Sarvatt: We didn't support any marvell flavour last cycle
<lool> I find it unfortunate that we're not supporting v5, but we're targetting high end ARMv7 netbooks/hardware so it makes sense to rip the benefits of the new instructions
<ogra> lool, swap stuff pushed btw, feel free to edit away
 * ogra builds a desktop image to see how swap affects it
<rjune_wrk> Morning ogra
<ogra> grmpf, why does it die now
<ogra> hmm, swapsizes above 1G seem to be no good idea
<Sarvatt> i'm so confused, marvell says "It contains advanced three-level branch prediction, a variable stage pipeline, and an integrated memory controller, providing unmatched high-end performance and low-power requirements. Compliant with the Cortex A8, Sheeva also supports both the ARMv6 and ARMv7 instruction sets, making it the world's first dual ARM ISA compatible CPU." but the docs for the sheevaplug say its a Sheeva 88SV131 ARM v5TE Pro
<Sarvatt> cessor Core with MMU and L1/L2 Cache
<ogra> the docs are right
<Sarvatt> so moral of the story is, if i buy one make a copy of the archive now before things move to armv6? :D
<suihkulokki> the moral of the story is to switch to debian \o/
<suihkulokki> Sarvatt: marvell is saying that sales stuff that they can produce ARMv6/ARMv7 cpu's based on sheeva tehnology, but their current cores are are ARMv5
<suihkulokki> s/sales stuff that//
<Sarvatt> yeah for armv5 i guess thats the best option, i really would like to get a v7 to play with instead but the sheevaplug looks like a better option for me for the price right now vs a beagleboard and i'm starting to get convinced other platforms arent going to come out anytime soon at a decent price :D
<lool> ogra: Hmm you seem to assume all vars aren't set in the env
<lool> ogra: You should be init-ing things like SWAPFILE or NOSWAP
<ogra> with ="" ?
<ogra> hmm
<ogra> thats a lot of extra empty lines ...
<lool> They are not "extra"
<ogra> heh
<ogra> yeah
<ogra> i'll add them
<lool> ogra: Since the script is so young you could still consider set -U
<rjune_wrk> what does set -U do?
<lool> sorry set -u
<lool> rjune_wrk: It errors out if you use an undefined var in an expansion
<rjune_wrk> Ahhh
<rjune_wrk> IOW, a very good habit.
<lool> A bit hard to retrofit in some pieces of code
<rjune_wrk> I believe that.
<Sarvatt> ogra: what cpu was rootstock (well qemu-arm) using by default before the cortex-a8 change?
<ogra> Sarvatt, the default versatile one
<ogra> it didnt specify -cpu before
<ogra> arm926 i belive
<Sarvatt> guess it uses "any" if you dont specifiy?
<Sarvatt> ah
<Sarvatt> its just nuts how much faster it is doing the second stage in a chroot in the android qemu (like 5 minutes there)
<ogra> what cpu is that ?
<ogra> (specifically at what speed does it run)
<ogra> i havent gotten qemu to do more than 200MHz here
<ogra> (on arm)
<Sarvatt> checking, battery about to die brb
<Sarvatt> http://sarvatt.com/downloads/emulator.txt
<ogra> BogoMIPS	: 736.22
<Sarvatt> thats on my faster pc that took almost 5 hours with rootstock the other day, will check what it is on the one i just built it on in a sec (atom cpu) :D
<Sarvatt> BogoMIPS	: 85.40
<ogra> right, thats a bit of a differentce
<ogra> *difference
<Sarvatt> its QEMU PC emulator version 0.8.2
<Sarvatt> but it builds fast on this 85 bogo mips one which is the weird part
<ogra> do you see the cpu speed in dmesg ?
<ogra> i'd really love to speed up debootstrap ... the rest runs totally fine, but the --second-stage processing is awful
<Sarvatt> http://sarvatt.com/downloads/emu-dmesg.txt
<Sarvatt> sorry, I had 512mb memory when I did it
<ogra> hmm
<Sarvatt> only 96 in that dmesg
<ogra> right, that means their qemu is hacked up i guess
<Sarvatt> yeah it is quite alot, thats why they havent upgraded it since theres so many changes against the old version
<Sarvatt> http://android.git.kernel.org/?p=platform/external/qemu.git;a=summary
<Sarvatt> doesn't help they do most of the development in a private perforce vcs and just import it in batches every now and then
<ogra> yeah
<ogra> not very clean
 * ogra rolls a qemu with lool's 512M patch and checks if that changes anything
<ogra> i was trying to add a gig of swap today, but that didnt make any speed difference
<ogra> (using awful hacks that added the swapspace before debootstrap runs)
<lool> Sarvatt: Oh Google also patches qemu for 512MB of RAM?  interesting
<Sarvatt> they have a custom platform that allows it I think?
<Sarvatt> not using versatile
<ogra> ah
<ogra> lool, did you notics any speed improvement with your patch
<lool> ogra: For what?
<ogra> qemu debootstrapping
<lool> I didn't load qemu with heavy workloads, so no
<ogra> ah
<lool> I don't think 256M or 512M make any difference for a debootstrap
<ogra> it might make a difference to the dpkg database processing
<ogra> it hangs endelss in the preprocessing in rootstock
<ogra> *endless
<Sarvatt> neat, XenARM has a paravirtualized goldfish platform from android qemu
<ogra> lool, hmm, your qemu patch doesnt work if applied against our package it seems :/
<ogra> DEBUG registered size=10000000 SDRAM at 0x0 with offset (nil)
<ogra> Not enough memory (requested_size = 268435456, max memory = 268435456)
<ogra> hmm, there seems to be a bunch of stuff missing in the patch
<ogra> lool, do you remember against which 0.10 version you made the qemu patches ?
<ogra> hrm, i suspect we apply some patch that breaks it
<lool> ogra: Against tip
<ogra> oh, i thought you did it against 0.10.x
<lool> ogra: No, it wont work against 0.10
<ogra> yes, i see that
<lool> memory management was redone and didn't allow for split memory banks in <= 0.10.x
<ogra> aaahh
<lool> ogra: Is it you or NCommander working on the gnome-keyring bug?
<ogra> on my list
<lool> NCommander: hey when do you usually roll the wiki page for next meeting?
<ogra> i need some more deskspace for the B1 though
<lool> NCommander: I'd like to add a couple of topics early in the agenda
<ogra> lool, i think he does it 10mins before the meeting :P
<lool> NCommander: Ah it would be cool if you could roll the pages now; otherwise I can send you topics by email
<NCommander> lool, I'll roll it a little later today (I usually do it a day or two after the meeting)
<NCommander> lool, just shoot me an email and I'll amend the pages
 * NCommander has to add somethinge sel as well
 * ogra wasnt aware NCommander speaks french 
<lool> NCommander: sent
 * ogra just remembered that sel is salt in french :)
 * NCommander knows no human language expect English
<ogra> lol
<ogra> partially at least :)
<NCommander> *grumble*
<ogra> wow, the tip qemu just trashed my filesystem in the image completely
<NCommander> o____o;
 * ogra takes another img ... 
<ogra> after the last two days i have plenty of them
<ogra> /etc/init.d/rc: line 74: /etc/default/rcS: No such file or directory
<ogra> error: '/etc/init.d/rc' exited outside the expected code flow.
<ogra> init: rc-sysinit main process (379) terminated with status 1
<Sarvatt> wow yeah i'm doing a second stage in 256mb ram and its alot slower
<ogra> geeez
<NCommander> o]______-o;
 * ogra sees no difference with 512M in qemu yet
<ogra> still sitting there ... doesnt move
<ogra> but i wasnt really expecting a difference through more ram
<ogra> that would have shown with the swap this morning already
<Sarvatt> i have the gui up this time too though, thats eating alot of the cpu time. 13% phone 11% alarm clock 9% google apps 21% dpkg kernel time 7% user 34% debootstrap user 14% kernel
<ogra> well, you are bootstrapping from a running system
<ogra> tahts a bit different anyway
<Sarvatt> hmm 141mb ram inactive, really doesnt need more ram.. its quite nice how in depth the android debugger is for profiling
<Sarvatt> ahhh i think the android environment tries to keep 50% ram free
<mcasadevall> lool, ogra, 13563 mcasadev  20   0  372m 367m   64 R 69.6 72.9   7:14.26 lzma
<mcasadevall> Looks like lzma is sucking down the machine's resources
<mcasadevall> and is paging out
<NCommander> wait a tick
<NCommander> never mind
<lool> mcasadevall / NCommander: You said yesterday it was working fine?!
<NCommander> lool, on my boards, I didn't build on rimu
<NCommander> lool, but the build passed on both rimu w/ dpkg-buildpackage, and under launchpad-buildd on my B2
<lool> So on rimu it's slow but on our boards it's not
<NCommander> lool, it passed though, 4 hours, no hang
<NCommander> (the build took 3:40 on my boards)
<lool> 4 hours is about the same you got and shorter than on the buildds
<NCommander> Right
<lool> NCommander: Chase IS to see what is different?
<NCommander> lool, infinity just went WTF when I told him it passed
<NCommander> since it shouldn't
<NCommander> rimu is setup the same way as the buildds expect access permissions, and it doesn't have launchpad-buildd
#ubuntu-arm 2009-07-17
 * ogra wonders what lool thinks about https://wiki.ubuntu.com/ARM/BuildEABIChroot :)
<Stskeeps> ogra: that's cool :) did you include debootstrap support for that or?
<ogra> no, just a wrapper script that calls first and second stage separately and sets --arch armel
<suihkulokki> A patch for qemu exists at http://qemu-arm-eabi.sourceforge.net/ to enable EABI support in qemu-arm
<suihkulokki> <- thats so outdated :P
<ogra> right
<ogra> suihkulokki, ??
<ogra> is there a newer one ?
<ogra> (that applies to 0.10.x)
<suihkulokki> EABI is supported even before 0.10.x
<ogra> weird
<Stskeeps> ogra: ah, but it copies in the qemu-arm static binary into the target temporarily i presume
<ogra> right
<ogra> not temporarily, else you couldnt chroot :)
<Stskeeps> ah yes
<ogra> suihkulokki, i find it intresting that i could never use qemu-arm properly then ... given that we had 0.10 in jaunty already
<suihkulokki> ogra: not really interesting.. just different (fixed in git head) issue
<ogra> ah
<suihkulokki> using git head highly recommended at the moment, as it will turn 0.11 any time now
<lool> ogra: I think that it's nice but not good enough for package builds
<ogra> lool, for home use its surely good
<ogra> my mesa build finished in about 2h
<ogra> on my laptop
<lool> I just don't trust it
<ogra> so if you want to do a pbuilder testbuild on armel before uploading etc thats surely a good way
<ogra> i wouldnt use it as a buildd :)
<lool> Right
<ogra> and i dont know how it will behave with neon and v7
<lool> That's not an issue
<ogra> its surely better than cross compiling the whole dep chain of gnome to testbuild a single gnome package in a cross compiler env
<lool> syscalls don't map one to one on armel and x86; I wouldn't trust that they are all properly wrapped and you might end up building packages which assume support for stuff which isn't truly supported or vice-versa
<ogra> yeah, its surely not for full production use
<ogra> but its *faaaaast* :)
<robert__> hello! I'm trying to build an arm-rootfs using rootstock (tried the older script from wiki, too), but it just hangs after starting qemu saying "installing core packages"
<ogra> it doesnt hang
<ogra> its just very slow inside the VM
<robert__> really? how long does it do "nothing" (or at least saying nothing"?
<robert__> I just got curious after half an hour or so
<ogra> give it time ... building the base system completely usually takes about 50min
<ogra> the apt stage later is faster
<robert__> oh, okay. maybe on my host it will take some hours :)
<robert__> I will wait. thanks a lot
<ogra> the 50min are on my laptop ... core2duo 1.8GHz
<ogra> slower machines will indeed take a bit longer
<robert__> okay. well, another question. what's a minimal system just providing X? I am currently trying xubuntu-desktop
<ogra> minimal system is really minimal ...
<ogra> just enough to boot
<ogra> if you only want boot and X add xorg
<ogra> a lightweight desktop would be lxde
<ogra> there are some examples on the RootfsFromScratch wikipage
<robert__> hm, I think I'll stick with xubuntu-desktop first, and maybe remove unneeded things later
<robert__> the created image should be bootable on an OMAP-board, right?
<ogra> its just a tgz
<ogra> yes, the packages should all run on OMAP
<robert__> okay, I'll try it later when the system is fully configured
<robert__> ogra: The script did not take too long, it booted the system a few minutes ago and is unpacking the packages now
<ogra> ah, good
<robert__> ogra: Do you know what compiler was used to build the armel packages?
<ogra> gcc
<ogra> depending on which release you use 4.3 or 4.4
<robert__> okay, thanks. that should fit with the other applications I plan to use
<robert__> ogra: "--seed build-essential,openssh-server" took about 15 minutes to build the full rootfs on an core2@2,66GHz
<ogra> sounds about right
<robert__> but the system does not boot, last messages is: " * Starting OpenBSD Secure Shell server sshd                             [ OK ]
<robert__> chown: failed to get attributes of `/var/log/dmesg': Stale NFS file handle
<robert__> chmod: failed to get attributes of `/var/log/dmesg': Stale NFS file handle
<robert__> /etc/rc2.d/S70bootlogs.sh: 61: cannot create /var/log/dmesg: Stale NFS file handle
<robert__> chgrp: cannot access `/var/log/dmesg': Stale NFS file handle
<robert__> mv: accessing `/var/log/udev': Stale NFS file handle
<robert__> "
<robert__> I don't understand why it seems to look for stuff on NFS at all...
 * ogra points to https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/391094
<ubot4> Launchpad bug 391094 in glibc "the "stale NFS file handle" error should be reworded" [Undecided,New]
<ogra> when did you check out the script ?
<robert__> an hour ago or so
<robert__> rev17 I think
<ogra> there was a bug where it was not properly unmounting the VM image
<ogra> you could do an fsck ... but its worrying that you still see it
<ogra> did you build for jaunty or karmic ?
<robert__> I built jaunty
<ogra> hrm, i checked that, thats bad
<robert__> the build was absolutely fresh, first boot
<ogra> yeah
<robert__> and I unmounted the image to where I unpacked rootfs correctly
<ogra> it didnt unmount the VM cleanly and then rolled a tarball that contained uncleared inodes
<ogra> you will see stuff being mentioned in the logfile i guess
<ogra> the best you can do is an fsck
<ogra> it will clean up the dangling inodes
<ogra> i will look deeper into that on the weekend
<ogra> i'm 100% sure its fixed in karmic, but i only tested one run under jaunty
<robert__> the image had wrong inodes, strange
<ogra> not if you think about it :)
<robert__> because qemu was killed while the fs was mounted?
<ogra> the image is built in a vm ... the vm isnt shut down properly ... then the image is mounted again and a tarball is created from the content
<robert__> but it still hangs with " * Starting OpenBSD Secure Shell server sshd                             [ OK ]
<robert__> chown: failed to get attributes of `/var/log/dmesg': No such file or directory
<robert__> chmod: failed to get attributes of `/var/log/dmesg': No such file or directory
<robert__> "
<ogra> you can create that file it shouldnt stop you from booting
<ogra> -rw-r----- 1 root adm 50862 2009-07-17 13:44 /var/log/dmesg
<ogra> should look like that
<robert__> well, but that should not stop the boot process, right?
<ogra> right
 * ogra has to go soon
<Sarvatt_> hmm 15 minutes? are you using amd64 or i386 on it robert__? its still around 3.5 hours for a build-essential,openssh-server karmic on a 2.4ghz turion x2 herex2 for some reason
<robert__> Sarvatt_: maybe 20 minutes, but not more
<Sarvatt_> debian is 20 minutes though
<ogra> amd64's qemu-syste-arm might run slower
<robert__> it's i386
<Sarvatt_> yeah thats what imthinking
<Sarvatt_> wow, cant type today :)
<ogra> anyway, i really have to go now ... i'll look into that tomorrow
<robert__> ogra: strange, /var/log/dmesg exists in the image
<Sarvatt_> thats a pretty crazy difference, i'll try it on i386
<robert__> all right, I'll try to get it running
<ogra> if you cant get it fixed, worst case use build-arm-rootfs for jaunty
<robert__> I will try that, too. just 15 minutes ;)
<robert__> ah, I tried jaunty. you mean k... (forgot the name :) )
<robert__> can karmic only be run with cortex-a8 as cpu? I need to use is for an 926
<Sarvatt_> you can use it for that now but its going to change soon to be armv6+,, would need to change rootstock around a bit because i think ogra moved it over to cortex in there
<robert__> yes, just a line to change. I was just wondering if the binary format changed for karmic
<Sarvatt_> not yet
<Sarvatt_> still armv5t arch default for gcc in karmic
<robert__> by the way, what do you use ubuntu/arm for? are there tablet pcs strong enough to run ubuntu on yet?
<Sarvatt_> i wish!
<Sarvatt_> i'm just using it for a build environment for a future system and to check for problems in pixman from git here
<robert__> so it's basically a "proof of concept" project at the moment?
<Sarvatt_> qemu is running so slow on my amd64 machines that i've resorted to using karmic in a chroot on my htc dream phone for all of that :D
<robert__> I'm planning to profile some applications on real hardware (OMAP developer board)
<robert__> hm, I have an htc himalaya laying around here, but never managed to run linux on it
<robert__> just managed to boot a kernel
<Sarvatt_> debian might be a better fit for both of those, jaunty and karmic arm are using arch armv5t with cortex-a8 tune for everything and i'm just guessing that would make things slower on the older hardware
<robert__> is there a list of CFLAGS used?
<robert__> ogra: karmic rootfs also hangs after "* Starting OpenBSD Secure Shell server sshd                             [ OK ]"
<robert__> I tried removing the symlinkgs in /etc/rc2.d which started services after sshd, without success
<robert__> I'll continue tomorrow. see you!
<Sarvatt_> ogra: holy crap, build-arm-eabi-chroot is great! thanks for packaging that!
#ubuntu-arm 2009-07-18
<mikestaszel> i have aa quick, n00b question
<mikestaszel> i've got a sheevaplug running ubuntu 9.04, but my question is - how do i cross-compile things on my i686 box for the ARM processor?
<mikestaszel> i've got the sheevaplug-gcc, but now what? :P
#ubuntu-arm 2009-07-19
<Sarvatt> https://wiki.ubuntu.com/ARM/BuildEABIChroot
<limon> hi i need boost-1.38
<limon> how can i find?
#ubuntu-arm 2010-07-19
<cwillu> rcn-ee, null pointer patch -> http://marc.info/?l=linux-netdev&m=127490516731906&w=2
<cwillu> going to try to run with that, and check if the memory leak was fixed elsewhere in 2.6.35
<cwillu> rcn-ee, okay, that patch fixes the null pointer at least, just got it booting
<cwillu> currently 36 objects in slab size-2048
<cwillu> ... and no increases yet
<cwillu> I'll ping back in an hour
<cwillu> rcn-ee, note that this is _with_ the micrel patches, plus an additional one which I'll email you
<cwillu> (er, it's actually the one from the link, so I'll only email you if you want a known-to-be-working copy of it :p)
<rcn-ee> cool cwillu, was playing with the patch.. http://marc.info/?l=linux-netdev&m=127490516731906&w=2 needed for 2.6.34 and 2.6.35 ? ;)
<cwillu> rcn-ee, haven't tested it under 2.6.34
<cwillu> rcn-ee, I'm suspicious that the null-pointer was a resulting from freeing the memory (i.e., what wasn't happening in .34 and earlier)
<cwillu> you're referring to the 2 -> 4 line?
<rcn-ee> okay, will queue up for 2.6.35 and get a build out, will test 2.6.34 tomorrow too just for kicks..
<cwillu> k
<cwillu> re, leak test, it's still holding at 36 objects
<cwillu> I've seen it go up to 100 or so, but it came back down
<cwillu> so, it seems to be working properly
<rcn-ee> yeah, it's more stablized then the previous version which shot up too fast..
<cwillu> going for a walk for an hour
<cwillu> I might dance a little while I'm walking :p
<cwillu> (road trip to replace / upgrade a bunch of hardware with bb + zippy's, and that wasn't going to work out to well if the max uptime of a zippy is a day :p)
<rcn-ee> you should... too much stress from the ks8851 driver for you this weekend..
<cwillu> now I can actually write features to pack in before I leave wednesday :) :D \o/
<rcn-ee> yeah that would have sucked big time, nothing like hardware that refuses to stay up..
<cwillu> yep
<cwillu> I knew I had this problem, but I thought I remembered that 2.6.33 didn't have it
<cwillu> as it turns out, I just never used the ethernet under 2.6.33 :)
<cwillu> I mean, I had a couple crappy workarounds, but I didn't want to have to explain their need to my boss :p
<cwillu> hardware that stays up is better
<rcn-ee> yeap... :) (crap replaced device 1 with 2, migrate to 2, shutdown 1, device 1 no longer repsonding..)
<rcn-ee> (device 2 no longer responding)
<cwillu> we get enough lightning strikes that I already have enough issues :p
<cwillu> had a customer call me up saying my system was rebooting every few seconds
<cwillu> he didn't feel the need to mention that his desktop was also doing the same
<rcn-ee> yeah, you need good ups in the summer.. (or two or three in line..)
<cwillu> in this case, if the power is out, they're not doing anything anyway
<cwillu> and I've gone through the sd testing routine and so forth
<cwillu> I'm actually considering reimplementing reboot as "sync; dontechodangerous b > /proc/sys-rq-trigger"
<cwillu> nice and quick :)
<hrw> mornig
 * cwillu_at_work dances with hrw 
<hrw> que?
<cwillu_at_work> my beagles are no longer leaking memory like little 2kb sieves
<furibondox> hi to everybody...
<furibondox> I've the same problem... segmentation fault on line 282 in rootstock
<furibondox> now I'm using a physical ubuntu Lucid installation
<furibondox> any idea?
<furibondox> http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg2382346.html
<rsalveti> furibondox: known issue
<rsalveti> furibondox: what rootstock version are you using?
<rsalveti> bug 604872
<ubot2> Launchpad bug 604872 in qemu-kvm (Ubuntu) (and 1 other project) "qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/604872
<rsalveti> depends on what you're installing
<rsalveti> sometimes it just get stuck and sometimes you'll get the segfault
<furibondox> rsalveti: the latest from ubuntu repository
<rsalveti> furibondox: you can try upstream version, I'm still fixing other bugs before releasing a new version
<furibondox> from svn?
<rsalveti> but you're still going to have the seg fault, the only difference is that it's going to try qemu more than once
<rsalveti> furibondox: bzr
<furibondox> ok
<furibondox> I will try
<rsalveti> bzr branch lp:project-rootstock
<furibondox> I'm installing bzr
<cwillu_at_work> rootstock reworked to use a chroot works great :)
<furibondox> cwillu_at_work: using chroot instead of qemu????
<cwillu_at_work> furibondox, chroot with qemu-static
<rsalveti> chroot with qemu
<furibondox> ah ok
<cwillu_at_work> it actually works spectacularly well :p
<rsalveti> furibondox: the problem is that the additional packages are installed with apt-get
<cwillu_at_work> as you can make use of as many cores as you have available, etc
<rsalveti> with a full vm
<cwillu_at_work> rsalveti, I reworked it to not use the vm at all beyond the chroot itself
<rsalveti> so, if you're still getting lots of segfault, try installing ubuntu-minimal and then installs the rest at your board
<rsalveti> cwillu: yeah, with root this is the best way
<rsalveti> still need to take a better look at that
<rsalveti> cwillu_at_work: gota a patch?
<cwillu_at_work> not really;  I've really had my way with the script
<cwillu_at_work> actually, I guess alot of it would be patchable
<furibondox> rsalveti: if I try to install ubuntu-minimal and then I create a script to install all the other packages I need and I call it with --script it should work?
<rsalveti> yeah, don't worry, will take a better look at it later
<cwillu_at_work> it's pretty straightforward though
<rsalveti> yep
<rcn-ee> it'll need some tweaks after the rootless changes.. ;)
<rsalveti> rcn-ee: yep, but still somehow an easy change
<rsalveti> furibondox: nops, because the script runs inside the vm
<rsalveti> what you can do is to mount the filesystem, copy qemu static on it and chroot
<rsalveti> then you are free to work on whatever you want
<furibondox> ok
<rsalveti> https://wiki.ubuntu.com/ARM/RootfsFromScratch
<rsalveti> furibondox: see sing qemu user mode emulation (with chroot)
<rsalveti> *using
<furibondox> OK, however now I try with the latest bzr release
<lag_> ogra: Can you send me the line to make boot.scr please?
<lag_> mkimage ***
<ogra> mkimage -A arm -T script -C none -n "Ubuntu boot script" -d <source> <target>
<hrw> ogra: how many bytes does mkimage adds to initrd?
<ogra> hrw, i think 64 ... one sec
<ogra> hrw, 72 :) https://wiki.ubuntu.com/ARM/BeagleEditBootscr
 * ogra knew he wrote that up somewhere
<hrw> thx
<slangasek> ogra: ok, why does this not work?: dd if=/mnt/uInitrd skip=1 bs=72 | gunzip -c | cpio -t
<lag_> ogra: Cheers
<ukleinek> ogra: a vanilla mkimage only adds 64, no?
<ogra> slangasek, probably because -T ramdisk adds different stuff
<ogra> ukleinek, might be, i think it varies with the comment (-n option)
<slangasek> ogra: well, so how do I unpack it? :)
<ogra> so the 72 might only be true if the comment is "Ubuntu boot script"
<ukleinek> ogra: IIRC, no
<ogra> slangasek, i never unpacked a uInitrd
<slangasek> the comment is "Ubuntu Initrd"
<ogra> ukleinek, funny, then i wonder why 72 works
<ogra> slangasek, you flipped bs and skip options ?
<ukleinek> http://git.denx.de/?p=u-boot.git;a=blob;f=include/image.h;h=bcc08d1a73224bb715d15983adea4767ce0e85fc;hb=HEAD#l176, 7*4 + 4 + 32
<slangasek> ogra: er, they're reversible
<slangasek> except that the way I've done it gives better performance :)
<slangasek> (and may spit a warning at the end due to a partial read)
<lag_> ogra: And the uimage mkimage script? (my 'useful commands' file is at home)
<cooloney> lag_: mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Ubuntu Kernel" -d zImage uImage
<lag_> Thanks cooloney
<rsalveti> cooloney: I'm looking at bug 566645, because I got the same thing here with latest lucid kernel
<ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 3) (heat: 49)" [High,Confirmed] https://launchpad.net/bugs/566645
<rsalveti> cooloney: if you want to test it here, or debug, I have the proper cable here
<cooloney> rsalveti: thanks, actually, i don't have the HW for testing,
<cooloney> rsalveti: can you test that lucid kernel? i did not prepare the maverick kernel
<rsalveti> cooloney: I got it with lucid
<rsalveti> didn't test maverick one yet
<rsalveti> neither upstream
<cooloney> rsalveti: cool, how's the result of lucid testing kernel?
<rsalveti> cooloney: if you're at prague we cat probably give you one beagleboard so you can reproduce it
<rsalveti> cooloney: same issue with latest lucid kernel, 2.6.33-502-omap
<cooloney> rsalveti: awesome, i am in kernel room and love to test
<ogra> robclark, https://code.edge.launchpad.net/~ogra/jasper-initramfs/trunk has the code in jasper_setup
 * robclark looks
<ogra> http://bazaar.launchpad.net/~ogra/jasper-initramfs/trunk/files rather
<rsalveti> cooloney: can you get by the arm room later? just because there are lots of cables and devices to be moving around
<ogra> GrueMaster, http://rcn-ee.net/deb/tools/UBOOT/u-boot-beagleboard-2010.03+r52+gitrca6e1c136ddb720c3bb2cc043b99f7f06bc46c55-r52.bin
<cooloney> rsalveti: no problem. i'd love to
<rsalveti> cooloney: don't need to hurry, will be here for the whole week :-)
<ogra> .oO(why did i just read "i love you" above ... )
<rsalveti> cooloney: now it doesn't work at all :D
<rsalveti> was finally able to test it
<Guest78932> cooloney: mkimage -A arm -T script -C none -n "Ubuntu boot script" -d <source> <target>
<cooloney> Guest78932: sudo dd if=/media/4C43-C886/boot.scr of=boot.script skip=64 bs=1
<cooloney> Guest78932: is this right? ^^
<Guest78932> Yep
<hrw> bye
<godstar> Hello
<godstar> I am looking to install Ubuntu on a Archos 5 IT, any pointers?
<loluengo> hi folks!
<loluengo> i have a little question
<loluengo> i'mm looking for  a small system to begin with ubuntu/arm development
<loluengo> i would like to have  some advice
<loluengo> which one you think is most suitable to begin??
<loluengo> beagleboard? or tincantools' hammer?
<pcacjr> loluengo, beagleboard
<loluengo> why?
<loluengo> i mean... why pcacjr?
<loluengo> any advantage?
<pcacjr> hmm
<pcacjr> it's simple to use
<pcacjr> you could get the beagleboard C4
<pcacjr> it's a good hw
<loluengo> i think the tincantools' nail kit is also very easy
<pcacjr> loluengo, well i've only been hacking on beagleboard lately
<pcacjr> loluengo, http://beagleboard.org is a good start
<loluengo> and flyswatter for jtag progamming?
<pcacjr> maybe :-), depends on you mate
<pcacjr> heh
<loluengo> any other not-so-expensive jtag emulator recommendation?
<godstar> What image do I use to install Ubuntu on an ARM device?
<loluengo> i looked at ti.com page and all of the emulator the recommend are VERY expensive!
<prpplague> loluengo: it all depends on what you want to do
<prpplague> loluengo: for alot of the basic operations of OMAP3 you don't really need a jtag
<loluengo> prpplague, what do you mean by basic operations?
<prpplague> loluengo: the OMAP3 has internal rom code that supports booting from SD card, uart, USB and nand flash
<prpplague> loluengo: so jtag isn't really needed for initial bootloader programming
<loluengo> prpplague, programming? debugging? tracing?
<prpplague> loluengo: basic programming debugging can be done via uart or other I/O, but if you really need jtag, you can use something like the flyswatter with openocd
<loluengo> hmmm
<loluengo> that sounds like a great PLUS for beagleboard
<loluengo> (over tincantools' hammer)
<prpplague> loluengo: beagle and hammer aren't exactly in the same ball park
<prpplague> loluengo: they are for different purposes
<loluengo> prpplague, why do you say that?
<loluengo> i see them similar
<loluengo> both are arm-based boards
<loluengo> both run linux
<prpplague> loluengo: the hammer was designed as a hardware developers platform with limited resources
<prpplague> loluengo: the beagle was designed as a software development platform with very little hardware expansion
<prpplague> loluengo: they are vastly different target audience
<prpplague> s/are/have
<loluengo> aaahhh ok
<loluengo> if i understood hammer is like a processor module - no peripherals added
<loluengo> and beagleboard has plenty of peripherals, intended to develop software
<prpplague> exactly
<prpplague> loluengo: the hammer is available with some peripherals, but those are mainly for testing and reference for the developer
<loluengo> good advice prpplague
<loluengo> i think hammer is for me...
<loluengo> my work is more hardware oriented than software oriented
<prpplague> loluengo: is there something specific you are planning to work on?
<loluengo> prpplague, yes... some kind of data logging device
<prpplague> loluengo: ahh
<loluengo> prpplague, not so interesting, but veeery useful
<james_> Hello
<james_> I'm trying to port Ubuntu to an armv6 device, that uses fbdev and am writing an xorg.conf
<james_> It uses a fbdev device
<james_> But I'm getting (ee) fbioblank Invalid argument error
<james_> Any ideas?
<james_> ogra_cmpc: Did you write rootstock by the way?
#ubuntu-arm 2010-07-20
<godstar> Ive been at this for several hours. Anyone care to help me install Ubuntu on a ARM device?
<cooloney> rsalveti: need i connect the beagle to HDMI display to login the board?
<rsalveti> cooloney: not actually, only serial is enough
<cooloney> rsalveti: http://pastebin.ubuntu.com/466351/
<rsalveti> cooloney: just a moment, going there
<cooloney> rsalveti: i looks to me it hangs there
<cooloney> *it looks
<lag_> sebjan: ping
<sebjan> lag_: pong
<lag_> Hey sebjan
<lag_> Do you deal with XM?
<sebjan> lag_: hi Lee, no I haven't yet. Someday maybe?
<lag_> So who's problem is it?
<ogra> lag_, go to #beagle and talk to koen, he should have working kernels
<lag_> ogra: Who's koen? Is he with us?
<ogra> he wors for TI and is the big beagle master
<ogra> he is also angstrom upstream
<ogra> *works
<lag_> Nice one, thanks
<hrw> ;)
<hrw> http://www.angstrom-distribution.org/demo/beagleboard/ will give you 2.6.32 for BB
<ogra> hrw, who is intrested in .32 nowadays :)
<ogra> we dotn wnat spiderwebs and dust on our kernels :)
<amitk> ogra: that is state of the art in angstrom land ;)
<ogra> yeah
<ogra> thats why the ship a duster with the images, right ?
<hrw> that's what TI used internally
<amitk> but yeah koen is a nice dude to know related to beagle issue, lag.
<ogra> well, we need patches for the maverick tree
<ogra> not for hardy ;)
<hrw> there are few more people on #beagle with XMs
<hrw> so maybe instead of waiting for _koen_ to appear better ask for XM kernel patches
<ogra> or look at rcn-ee's trees ;)
<ogra> since his binaries seem to work fine
<ogra> *and* are up to date
<hrw> https://code.launchpad.net/~beagleboard-kernel/+junk/2.6.35-dev
<hrw> you mean that?
<cwillu_at_work> hrw, yep
<cwillu_at_work> binaries are available as well
<cwillu_at_work> http://rcn-ee.net/deb/
<rsalveti> cooloney: your sd card reader is here, if you want to take it back :-)
<cwillu_at_work> incidently:  rcn-ee, I've got patches to allow the re-use of the kernel tree, so you don't end up rechecking out (even from a local copy) multiple times, and which ends up making for far quicker compiles if possible
<cwillu_at_work> to build_deb and company
<cooloney> rsalveti: yeah, thx for reminding.
<cooloney> rsalveti: but i failed to see any oops
<rsalveti> cooloney: with your kernel?
<rsalveti> cooloney: I remember that your kernel is installed on the sd card
<rsalveti> you can try the 501, like I did yesterday
<rsalveti> then you can try to reproduce the issue
<rsalveti> because it'll use the musb as module and load it as needed
<cooloney> rsalveti: ok, i understand.
<cooloney> rsalveti: $ ls
<cooloney> boot-35.scr  boot.scr  uImage  uImage.35  uImage-lucid  uInitrd  uInitrd.35  uInitrd-lucid
<cooloney> i got these files
<rsalveti> cooloney: probably if you just copy uI*-lucid for uI* it should run the 501 by default
<cooloney> rsalveti: ok, thx
<rsalveti> I remember I created these files to test 501
<cooloney> rsalveti: pls take a look at http://pastebin.ubuntu.com/466386/
<cooloney> rsalveti: i tried copy over uI*-lucid and uI*.35
<cooloney> rsalveti: and got that issue
<rsalveti> cooloney: just a sec
<cooloney> rsalveti: np
<lag> cooloney: mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d ./initrd.img-* ./uInitrd
<ogra> lag, careful with wildcards ;)
<ogra> you might have more than 1 ./initrd.img-* in that dir
<cooloney> robclark: hdmi error: Failed to set PHY power mode to 0
<ogra> cooloney, buy a better monitor
<NCommander> ogra: http://paste.ubuntu.com/466397/
<cooloney> ogra: i love my viewsonic at home
 * ogra is hapy with the samesung he has
<hrw> ogra: cheap chinese samsung fake clone?
<robclark> cooloney: hmm, ok, I get that 'PHY power mode' on my board too (but still monitor works)..
<cooloney> robclark: oh, weird. need i bring my board for you ?
<robclark> cooloney: we can if you want...  I'm just installing meld to more easily diff the two dmesg txt files to see if I can spot some relevant difference
<cooloney> robclark: yeah, i use meld heavily
<cooloney> rsalveti: if you can help to test Maverick on beagle for that OTG bug, it will be very helpful
<rsalveti> cooloney: yep, I'm just installing maverick, going to take a while but I believe it'll be ready for today ;-)
<cooloney> since i just checked th patches for musb driver, .34 lucid kernel missed lots of patches from current upstream
<cooloney> but those patches are in Maverick .35 kernel now. i think
<rsalveti> cooloney: yep, also noticed that
<cooloney> rsalveti: awesome, man, thx
<rsalveti> np
<robclark> cooloney: fwiw, your monitor is working now..  after letting it sit for a while
<cooloney> robclark: really.
<robclark> I do see some different bits set in one of the hdmi irq status registers with your board...
<robclark> I'm trying to find what they mean.. maybe give some hint about the issue
<ogra> rsalveti, lp:~jasper-initramfs
<ogra> lag_, http://gitorious.org/beagleboard-validation/linux/commits/beagleboardXM
<ogra> or rather http://gitorious.org/beagleboard-validation/linux
<rcn-ee> hey ogra, was reading #beagle, your guy's xm doesn't boot?
<ogra> rcn-ee, it boots but shows some opses
<ogra> rcn-ee, the worse part is that USB and the NIC dont work
<rcn-ee> there's one oops for me.. the usart3 (i think there's a patch for that on l-o) but nic and usb work for me..
<ogra> the oopses seem harmless (trying to probe uart3 and failing because it doesnt exist)
<rcn-ee> but i also have the half memory version.. (you guys might have the 512Mb)
<lag_> Hi rcn-ee
<rcn-ee> hi lag_
<lag_> We've been waiting for you :)
<ogra> rcn-ee, well, we're using a pretty plain 2.6.35 mainline
<ogra> rcn-ee, so i suspect we miss some extra patches
<rcn-ee> yeap me too.. here's what you need: http://bazaar.launchpad.net/~beagleboard-kernel/+junk/2.6.35-devel/files/head:/patches/xm/
<rcn-ee> (most borrowed from sakoman)
<ogra> lag_, ^^^
<ogra> :)
<rcn-ee> the xm-dvi-ehci will fix the ehci..
<lag_> I see :)
<lag_> Do I need all 4 patches?
<ogra> they seem to make sense
<rcn-ee> yeah, all four.. most are just macro's which will be upstream eventually anayways..
<ogra> and dont look like they could cause regressions
<rcn-ee> nope, not for me atleast, same kernel is booting fine with no regressions on my bx's, cx's, xm, overo, igepv_2..
<ogra> cool
 * ogra needs to try the new gumstix board h just got
<ogra> though i guess the plain beagle MLO/u-boot wont work on it
<rcn-ee> actually.. if you've bumped to 1.44ss and 2010-03 xm rev A support is included.. ;)
<ogra> lag_, btw, your panda install is done, want me to bring you the SD ?
<ogra> rcn-ee, yeah, XM is, we tested that already, (i'm still using 2010-03-rc though)
<lag_> If you'd be so kind
<ogra> i just got one of the 512M gustix though
<lag_> Well I'll apply and try to get them pushed into our kernel
<rcn-ee> yeap, that one is fine.. 2010-03-rc was the first.. btw keep an eye on sakomon's tree, there might be some memory tweaks for the xm (512Mb revision)..
<ogra> great, i will
<rcn-ee> btw, one thing odd about the xm's onboard lan, it comes up as a usbX device, which if you also have the gadget driver loaded it might confuse users (since that's usbx too) i've though about tweaking it to a normal 'ethX'...
<ogra> ah, seems its the same HW as the panda has
<ogra> panda alo has a usb0
<ogra> *also
<rcn-ee> yeap the lan95xx, usb/eth hub..
<rcn-ee> or wait, doesn't the panda have the smsc...
<ogra> yeah
<ogra> with a good bunch of issues still
<rcn-ee> i just got my booting.. ;) no usb yet for me...
<ogra> your panda ?
<rcn-ee> yeap... ;)
<ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100720.2/
<ogra> grab the omap4.img.gz :)
<rcn-ee> will do and give you some results
<ogra> just dd it to an SD and boot (you need monitor, kbd, mouse attached)
<ogra> (after gunzipping indeed)
<rcn-ee> i haven't posted much on #pandaboard, but have you guys forwared ported the u-boot patches to some less ancient?
<ogra> no, linaro is working on such stuff
<ogra> but thats will likely still take a while
<ogra> i just took the panda branch from gitorious and made some changes to the defaults
<ogra> (hush shell, script support and loading boot.scr by default form first mmc partition if it exists there)
<rcn-ee> i was kinda hoping for one kernel, but it doesn't look yet like you can share a non smp target with an smp one in arm yet.. (or my compiler is too old 4.3.1)
<tmzt> because of how cores are initialized?
<ogra> rcn-ee, there is work going on towards a unified oma kernel
<ogra> *omap
<ogra> but that will also still take a while
<ogra> will probably hit the streets together with a unified u-boot version ;)
<NCommander> rcn-ee: also, very few devices are SMP ARM (panda is the only board I've seen with a multicore chip)
<ogra> there will be more soon
<ogra> isnt the tegra also SMP ?
<NCommander> ogra: um, possibly?
<NCommander> no idea
<ogra> i think its A9 dual core
<lag_> rcn-ee: Hi
<rcn-ee> hi lag_
<rcn-ee> yeap the tegra is dual core...  otherwise it's still early for dual arm devices, the omap35/36 really didn't take off til a year after the beagle..
<lag_> rcn-ee: Would you mind sending me a working kernel binary please? With USB and Eth working?
<lag_> I would like to test it before my kernel compiles
<rcn-ee> so maybe a year after the panda is released we will see some omap4 devices..
<lag_> If it's not to much trouble
<rcn-ee> sure lag_ lucid or maverick?
<ogra> mavrick
<ogra> +e
<lag_> You have Lucid working on XM too?
<rcn-ee> 2.6.34 or 2.6.35.. (of course.. ;) )
<ogra> .35
<lag_> ogra: You have a big nose ;)
<ogra> haha
<rcn-ee> lag_, http://rcn-ee.net/deb/maverick/v2.6.35-rc5-dl6/linux-image-2.6.35-rc5-dl6_1.0maverick_armel.deb
<rcn-ee> just don't use a zippy2 on that, it's missing a patch that's in dl7
<lag_> So you downloaded our kernel, applied those 4 patches and everything sprung to life?
<lag_> I don't even know what zippy is
<rcn-ee> actually it's my own mainline +patches blend... config's are very similar..
<hrw> rcn-ee: so far Ubuntu/Linaro people use plain BB - no extensions
<lag_> He was a children's TV character when I was a kid :)
<cwillu_at_work> I wuv my rcn-ee
<hrw> I suppose that I am the only one in Linaro/Ubuntu team who has BB expansion board
<rsalveti> I got one zippy 2 here, but doesn't work by default, still have to apply some patches
<rsalveti> mainly on rcn-ee tree, that got from angstrom
<cwillu_at_work> rsalveti, zippy2's ethernet will leak memory without a patch
<rsalveti> cwillu_at_work: what patch?
<cwillu_at_work> a 2 needed to be a 4
<cwillu_at_work> rcn-ee has it
<rsalveti> oh, ok, I see it
<cwillu_at_work> otherwise it'll leak about 2k every second or two while an ethernet cable is connected
<lag_> That's the patch that ogra gave me and said it will make USB work, lol!
<rcn-ee> yeap, and the beagle is building maverick's dl7 right now.. it's just no uploaded.. yet..
<cwillu_at_work> slabtop -s s -> size-2048 will get into the 20,000 alloated range, and then everything will stop working :)
<ogra> lag_, i guessed :)
<lag_> :D
<cwillu_at_work> if you really need a binary with the patch in a hurry, I can send it to you
<ogra> we rather need a working ubuntu kernel :)
<rsalveti> yep :-)
<cwillu_at_work> ... with btrfs compiled in :p
<hrw> ogra: binary which works can be used to test does lag's XM is working at all
<cwillu_at_work> none of this initramfs nonesense
<cwillu_at_work> -e
<rcn-ee> cwillu_at_work, noticed there was more btrfs patches last night.. hopefully it gets in 2.6.35-rc6..
<ogra> hrw, well, we will just grab yours if lag_'s doesnt work :P
<cwillu_at_work> oh, there's going to be lots of btrfs patches for the foreseeable future
<cwillu_at_work> rcn-ee, if you really wanted to be my friend, you'd pull btrfs directly from git in patch.sh :)
<rcn-ee> is it just usb/dss2 that's not working on the xm, those 4 from me will take care of it..
<hrw> ogra: mine? hah
<ogra> indeed yours :)
<rcn-ee> i thought about it... ;) since my builders will be free again in a couple hours..
<cwillu_at_work> also, did you want to look at the changes I made to build_deb.sh to make it re-use the build environment?
<rcn-ee> sure, cwillu_at_work i'd take a look at those tweaks..
<cwillu_at_work> http://pastebin.com/rkgRsXnH
<cooloney> rsalveti: if the OTG port works, it is supposed to support a USB mouse connected with the USB mini connector you gave to me, right?
<cwillu_at_work> rcn-ee, patch isn't terribly clean, as your indentation is atrocious :p
<rsalveti> cooloney: without a powered hub, don't know
<cwillu_at_work> rcn-ee, so what we do is...
<cooloney> rsalveti: i tried powered hub, the usb mouse doesn't work
<rsalveti> cooloney: I'll just test with maverick, rebooting...
<cooloney> rsalveti: cool
<rsalveti> cooloney: with 501?
<cooloney> rsalveti: with 501, if the oops shows up, the musb driver does not work at all
<cooloney> so the usb mouse won't work
<rsalveti> cooloney: yeah, only works when you don't get the oops
<cooloney> i never see the oops is gone with 501 kernel
<cwillu_at_work> never delete KERNEL, and only clone it if it doesn't exist already.  Then, before checking out a given version, we reset the working copy (which doesn't delete the partial files, so compilation will be quicker if appropriate), and then delete whichever branch we're about to create if necessary
<rsalveti> sometimes it does work
<rcn-ee> cool cwillu_at_work yeah the patch looks pretty clean and get what your doing.....  yeah it's indentation sucks big time, (damn editor)..
<cooloney> rsalveti: i still think we need to build in the modules and config the port as OTG
<cwillu_at_work> what editor are you using?
<cooloney> rsalveti: currently, we just config it as host
<cooloney> not OTG
<rcn-ee> gedit and my left pinky... so it's mostly me to blaim.. ;)
<cwillu_at_work> gedit isn't that bad Lo
<cwillu_at_work> :p
<cwillu_at_work> I do have some sanity plugins for it though
<cwillu_at_work> (hippy text completion, incremental search improvements, an interesting take on code folding (which is a bit crashy), automatic session save and restore, etc
<cwillu_at_work> (the code folding hide everything except for lines containing the word under the cursor, or the selected text, or the currently searched-for text
<tmzt> folding?
<cwillu_at_work> hides, rather
<tmzt> oh, not like msvs
<cwillu_at_work> tmzt, that's traditional code folding
<cwillu_at_work> which I never had much use for
<rsalveti> cooloney: oh, ok
<rcn-ee> it's scary some questions people ask for their thesis work.. ;)
<cwillu_at_work> I think I hate quilt
<hrw> quilt is nice
<cwillu_at_work> yes, but how the hell do you set it up the first time?
<cwillu_at_work> it's not putting patches into debian/patches, and quilt setup doesn't have any place to say where I want them
<hrw> QUILT_PATCHES=$PWD/debian/patches ?
<hrw> and xport it
<persia> There's a lovely little .quitrc in /usr/share/doc/quilt that automates that bit.
<cwillu_at_work> so a quilt'ed source package still requires a random environmen...
<cwillu_at_work> it'd be nice if that was documented in dpkg-source :p
<hrw> cwillu_at_work: do I force you to use quilt? patch is easy to use...
<cwillu_at_work> hrw, I need an old inkscape version compiled for arm, and although there's no patch or series set up, it's complaining
 * cwillu_at_work continues grumbling
<cwillu_at_work> but if I understand correctly, a quilt'd source package doesn't actually work with quilt until you've set that environment variable?
<hrw> I assume "dpkg-source -x package.dsc; cd package-*;debuild -b"
<cwillu_at_work> dpkg-buildpackage you mean? :p
<hrw> prefer debuild as it keeps build log for me
<hrw> unless I need to pass env vars which debuild clears
<cwillu_at_work> and you should be able to quilt new <patch>; quilt edit <file>; dpkg-buildpackage, and not have to quilt pop -f?
<cwillu_at_work> was complaining about the patch (that it just made) not unapplying cleanly
<cwillu_at_work> which is inane, but probably my fault
<cwillu_at_work> grumble?
<ogra> cwillu_at_work, https://wiki.ubuntu.com/PackagingGuide/PatchSystems
<cooloney> rsalveti: i boot once without the oops and usb mouse + usb hub + external power works.
<rsalveti> cooloney: yeah, that happens sometimes
<rsalveti> rcn-ee: do you know why you're applying the fifo-mode patch for musb?
<rsalveti> changing the fifo mode
<cwillu_at_work> ogra, thanks;  it looks like the source of my grief is that the source package was slightly malformed
<cooloney> rsalveti: i am building a kernel which enable the debug in musb otg driver
<rsalveti> cooloney: ok
<rsalveti> that can help
<lag> hrw: Are you still about?
<hrw> lag: Chopin/Linaro room
<lag> hrw: My hardware is plugged in :)
<hrw> few minutes ok?
<hrw> lag: sakoman_ is present in #pandaboard
<lag> I saw
<hrw> re
<rcn-ee> rsalveti, errata.. the omap34/omap35 musb memory is actually 4kb not 8kb which is what fifo=4 is setup for.. bug check: transfer 2GB from two high speed devices on the musb bus (harddrive, eth) and run md5sum, they'll mismatch..  last i heard the musb guys were going to apply the fifo based on board-device.c
<rcn-ee> but right now it isn't a per device setting and just a global one..
<rsalveti> rcn-ee: oh, ok, makes sense now
<rsalveti> cool, thanks
<rcn-ee> we ran into more often in the bx days.. but with good ehci ports no one notices it any more.. ;)
<rsalveti> rcn-ee: I'm also looking at the micrel and zippy patches, do you know if any of those are proposed upstream already?
<rsalveti> or you're just basically maintaining at your patch tree
<rsalveti> rcn-ee: nice to know, going to test it here
<rcn-ee> they are atleast from micrel, but the netdev maintainers keep shooting them down.. ;)
<rsalveti> trying to make the otg port to work with default ubuntu kernel
<rsalveti> don't know why it's not working correctly
<rcn-ee> i just keep forward porting and testing them on my self (since we sell zippy boards at digikey)
<rsalveti> rcn-ee: haha, ok :-)
<rcn-ee> i still think it's a config issue. take a look at my defconfig, i'm running bx's with usb hardrives on the musb port...
<rsalveti> rcn-ee: yep, that's what I'm checking now
<rsalveti> just installed your latest kernel and it worked fine
<rcn-ee> good to hear, i try to keep it pretty in sync with ubuntu's config options just to keep me 'sane'... but main things i'm currently working on dspbridge and panda integration in the same kernel..
<hrw> igep suxx
<rsalveti> hrw: why? :-)
<rcn-ee> yeah why, it's slightly faster then my C4 board at gcc bootstrap? ;)
<hrw> the one which steve brought has something with mmc - but some of you already know that
<armin76> hrw: i can talk bad about a beagle which hanged from time to time :)
<hrw> armin76: beagle or beagleboard?
<armin76> beagleboard
<armin76> is there a beagle?
<hrw> there was
<hrw> few years ago netherlands company had a linuxpda with that name
<hrw> never got to the market but was shown in few places and was supported in openembedded
<rcn-ee> rsalveti, one note on the micrel patches too..  Wireing up with the buddy= variable most of that came from Koen, it works quite well for detecting the zippy1/2 boards on boot and loading the correct drivers.  I'm working with someone too add an 'lcd' module and will use a simlar setup..
<rcn-ee> none of that is upstream, so who knows if it'll be excepted..
<rsalveti> rcn-ee: yep, also just noticed that
<rsalveti> first time I get a zippy on my hands
<rcn-ee> it makes a prety big mess of beagle.c file. ;)
<rsalveti> zippy2
<rsalveti> :-)
<rcn-ee> they are actually 100% identical except the eth spi device..
<rsalveti> yep, but you need the correct id in order to load the correct driver
<hrw> [   42.668029] mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
<hrw> [   42.781280] mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
<rcn-ee> yeap, and the first big shipment of zippy2's we got in march? had the zippy1 setting on the i2c bus. ;)
<rcn-ee> it's simple to reprogram, but it's faq #1 on them..
<rsalveti> rcn-ee: hehe, mine also seems to be with the wrong id
<rsalveti> yep
<ssvb> hrw: but at least it is probably not igepv2 design defect, but just one broken board? unlike USB on beagleboards older than rev C4...
<rcn-ee> till you reprogram it, just force buddy=zippy2 in your boot.scr
<rsalveti> rcn-ee: do I need any jumper to disable the write protection?
<hrw> ssvb: yep
<rcn-ee> yeap.. (crap i need one at home)
<hrw> ssvb: my c3 bb works quite good with extra capacitor added
 * cwillu perks up
<rcn-ee> cwillu, your patch works good, defintelly speeds it up. now i can't get my coffee. ;)
<cwillu> :)
<rsalveti> rcn-ee: hm, jp 1
<cwillu> ya, I was actually shocked how much faster the system was even shortly after a reboot
<rsalveti> needs to find a jumper around
<cwillu> rsalveti, yes
<cwillu> I just use an alligator clip
<rcn-ee> steal it from one of the freescale boards, they always have extras.. ;)
<rsalveti> yeah, will try to find something to connect the pins :-)
<rsalveti> oh, good idea :-)
<cwillu> rcn-ee, my rootstock image programs x-load/u-boot to nand, updates the eeprom if it hasn't been already, and a few other odds and ends automatically :)
<cwillu> I can go from source to a burned sd card, and then booting a beagle and programming the zippy and such under 30 minutes :)
<cwillu> it's been a good week :)
<rcn-ee> yeah, i think it would be a good idea to put up a eeprom script for new zippy2 owners..
<cwillu> sec, let me grab it
<cwillu> it's a single upstart job
<rsalveti> it'd help a lot, for sure
<cwillu> it'll try each boot until it succeeds
<rcn-ee> that might be overkill..  if your zippy2 is detected as a zippy1 run this script
<cwillu> rsalveti, rcn-ee, fixups.conf
<cwillu> fixups.conf
<cwillu> ...
<cwillu> http://pastebin.com/FjyjvdSN
<cwillu> middle click wasn't working :p
<cwillu> that's basically all the upstart script is anyway
<hrw> ok, one hour passed - igep goes back to the box
 * hrw -> movie
<rcn-ee> yeap that script looks good and will do it..
<cwillu> rcn-ee, there was a cool looking auto-edid patch that I want to experiment when I get back too
<cwillu> i.e., detecting monitor resolution at boot
<cwillu> here's a question:  how long does it usually take rootstock to run?
<rcn-ee> that would be very useful, i've thought of it a couple times, the drm layers has all the good edid stuff nowdays..
<rcn-ee> it locks up for me in 25 minutes (maverick alpha-2+) at ldconfig or somethign
<cwillu> heh
<cwillu> you guys are still on a full qemu vm?
<rcn-ee> that one yes.. otherwise 3-4hours on my beagle..
<cwillu> I really should figure out who needs which patches :)
<cwillu> rcn-ee, I have a finished image in 21 minutes
<rsalveti> cwillu: I'll try to change it to use full vm just for user
<rsalveti> as root you can easily do most of the steps on user mode emulation
<rcn-ee> i still tar it up, which kills the poor beagle..
<rsalveti> as you're doing it already
<cwillu> yep
<rsalveti> just have to find some time during this week
<rsalveti> will also try to push the native rootstock stuff
<rsalveti> to run it at an arm board
<cwillu> I'm just outputting a tarball;  I have separate mkcard script which actually writes the image / creates an image file if desired
<rcn-ee> btw, just resynced my rootstock on arm patch on top of rootstrock trunk: http://bazaar.launchpad.net/~beagleboard-kernel/+junk/image-builder/annotate/head:/patches/native-arm.diff
<cwillu> I'm going to be out of town till friday, but then I'm hoping to take some time off
<rsalveti> rcn-ee: nice, will take a look at it later
<lapada> hi, my keyboard  and mouse drivers are not loading so i can not operate, can any one please tell me what could be the issue..?
<rsalveti> I'm at prague, so most of the time we're just discussing and debugging stuff, hard to find time for real coding
<rcn-ee> i haven't tested it yet, that node has been building kernels, but it's a forward port of my previous stuff.
<cwillu> lapada, 2.6.35 kernel?
<cwillu> lapada, you're missing a patch, and you actually don't have _anything_ that uses modules
<lapada> dont know
<cwillu> lapada, easiest answer would be to drop back to 2.6.34, or to use the very latest rcn kernel
<cwillu> or it might be something else entirely :p
<lapada> it is from the image of ubuntu site
<rsalveti> rcn-ee: yep, just changed the config file and the musb is now working beautifully
<lapada> lucid 10.0.4
<cwillu> ah, no idea then :p
<rcn-ee> rsalveti, good to here.
<rsalveti> rcn-ee: but will probably have the fifo bug, will also test that later
<lapada> I am following this procedure https://wiki.ubuntu.com/ARM/BeagleNetbookInstall
<rcn-ee> rsalveti, for the fifo bug you can use this for justification.. http://www.spinics.net/lists/linux-omap/msg29025.html
<lapada> but when in installer screen no keyboard nor mouse responds
<rcn-ee> actually this one is the original. (it was tweaked in that last post) http://www.spinics.net/lists/linux-usb/msg25777.html
<cwillu> lapada, what version of the beagle?
<cwillu> and which usb port are you using?
<lapada> rev c4
<cwillu> and the ehci port (the big one) or musb (the small one next to the power cable)
<cwillu> ?
<rsalveti> rcn-ee: nice, thanks a lot
<lapada> the big one
<rcn-ee> yeap no problem, personally fought that bug for a good 3-4 months.. (i think i was the first to run big harddrives and ethernet adapters on the original bx's)
<lapada> with a hub connected
<cwillu> not sure, sorry
<rcn-ee> lapada, is it a powered usb2.0 hub? does it help if you unplug and replug?
<rsalveti> hm, hungry, will try to get something to eat around and will be back soon
<cwillu> sleepy, back in a few days :p
<lapada> it is not a powered hub, but the power source of beagleboard can handle
<lapada> and besides already used the same hub with android distribution
<rcn-ee> ehh.. lapada back in the 2.6.29 days which is what most android for beagle uses, it kinda worked...  but wasn't suppost to..  i'd really get a powerd hub...
<lapada> ok, I think I can get one
<lapada> but, any other idea if the problem isnt the hub?
<lapada> one little doubt
<lapada> after installing ubuntu lucid on beagleboard, after complete 100%, I get just a purple screen, after waiting a while I removed the sd card and booted the bb, but no ubuntu at all!!!!!!!!
<lapada> I receive the message:       ERROR: can't get kernel image!
<lapada> what should I do?
<rsalveti> lapada: how did you actually install it?
<lapada> form the ubuntu site I used the ubuntu-10.04-netbook-armel+omap.img
<hrw> netbook image on normal beagleboard? insane
<lapada> used the image writer to write to the sd card
<lapada> boot the beagleboard with the sd card and complete the installation of ubuntu 10.0.4
<lapada> https://wiki.ubuntu.com/ARM/Beagle
<lapada> the problem is I completed the installation, till finish 100%
<rsalveti> hm, didn't try lucid myself but GrueMaster tested a lot, for sure
<lapada> but when restarting beagleboard it says https://wiki.ubuntu.com/ARM/Beagle
<lapada> ops
<lapada> but when restarting beagleboard it says ERROR: can't get kernel image!
<rsalveti> it should just put the uImage and uInitrd on nand, set the boot.scr and reboot it
<rsalveti> lapada: when do you get this error, at the bootloader?
<lapada> yes
<rsalveti> it could be that your uboot is not reading the boot.scr, for some reason
<rsalveti> lapada: can you paste the full uboot log for me?
<lapada> I will try
<rsalveti> hrw: I'm testing maverick on a c4 and it's working quite well actually
<rsalveti> lots of bugs still, but getting better
<rsalveti> bootchart is installed by default, so the boot is slower than it should
<lapada>     NAND read: device 0 offset 0x280000, size 0x400000                                4194304 bytes read: OK                                                          Wrong Image Format for bootm command                                             ERROR: can't get kernel image!
<lapada> the ubuntu is installed in the usb pen drive
<rsalveti> try to get at the bootloader (just press any button while booting) and run the following commands:
<rsalveti> mmc init
<rsalveti> fatload mmc 0 0x82000000 boot.scr
<rsalveti> source 0x82000000
<lapada> ubuntu is booting
<lapada> but I guess it is the installer..
<lapada> yep, the installer again
<lapada> isn't booting by
<lapada> isn't booting by usb
<rsalveti> lapada: just remove your sd card, see if it works
<rsalveti> if you installed it at the usb, than it should boot fine
<lapada> but it is NOT!!!!
<lapada> No MMC card found
<lapada> Booting from nand ...
<lapada> NAND read: device 0 offset 0x280000, size 0x400000
<lapada>  4194304 bytes read: OK
<lapada> Wrong Image Format for bootm command
<lapada> thats it
<lapada> ERROR: can't get kernel image!
<rsalveti> it seems that your uboot env is loading the script as it should, and if when loading it, for some reason it's probably setting the root partition to /dev/mmcblk0p2 instead of the usb one
<rsalveti> *is not
<rsalveti> I should get some sleep :-)
<lapada> it makes sense
<lapada> how can I change this?
<lapada> pls dont sleep
<rsalveti> lapada: to change the uboot env you just need to set up the correct arguments, or flashing/updating it to have the default behavior
<rsalveti> now to change the boot.scr you'd need access to the nand partition
<rsalveti> you can try to set up the bootargs by hand and try to booting the rootfs from your usb
<rsalveti> and after booting it, you can mount the nand partition and fix the boot.scr by hand
<rsalveti> fatload mmc 0:1 0x80000000 uImage
<rsalveti> fatload mmc 0:1 0x81600000 uInitrd
<rsalveti> setenv bootargs  ro elevator=noop vram=12M omapfb.mode=dvi:1280x720MR-16@60 root=/dev/sda1 fixrtc console=ttyS2,115200n8
<rsalveti> bootm 0x80000000 0x81600000
<rsalveti> lapada: try this after pressing some button and getting into the uboot command line
<lapada> i'm back
<pcacjr_> <rsalveti> I should get some sleep :-)
<pcacjr_> i'm sure you should
<lapada> waaaaaaaait
<lapada> I was disconnected
<lapada> can you send those commands again
<lapada> fatload...
<pcacjr_> fatload mmc 0:1 0x80000000 uImage
<pcacjr_> atload mmc 0:1 0x81600000 uInitrd
<pcacjr_>  setenv bootargs  ro elevator=noop vram=12M omapfb.mode=dvi:1280x720MR-16@60 root=/dev/sda1 fixrtc console=ttyS2,115200n8
<pcacjr_> bootm 0x80000000 0x81600000
<pcacjr_> enjoy
<rsalveti> yep, but actually this should try to load from the first sd partition, and not nand
<rsalveti> for lucid the kernel should be in nand, just maverick that gets it installed at the sd card
<pcacjr_> rsalveti, then he should change to the proper partition
<rsalveti> argh, need to get this boot.scr from lucid
<pcacjr_> would it be /dev/mmcblk0px ?
<rsalveti> pcacjr_: this is for the sd, on linux
<rsalveti> but he first needs to load the uImage and uInitrd from nand, put it on memory, setup the correct arguments and load the images
 * pcacjr_ nods
<rsalveti> so he can actually boot the board
<pcacjr_> i see
<lapada> probably
<pcacjr_> so would he have the rootfs on eMMC ?
<rsalveti> let me check the flash-kernel package from lucid
<rsalveti> pcacjr: on usb
<lapada> and now I go sleep
<lapada> thanks all
<pcacjr_> lapada, cya
<pcacjr_> rsalveti, ok
#ubuntu-arm 2010-07-21
<rsalveti> cooloney: I updated the bug with another defconfig
<rsalveti> cooloney: with this defconfig I got the musb working with maverick kernel, now just need to identify what needs to be changed to make it work by default
<cooloney> rsalveti: awesome
<cooloney> rsalveti: let me check
<rsalveti> cooloney: but is a little painful to recompile it, install and test :-)
<cooloney> rsalveti: is that defconfig the omap3_beagle_defconfig?
<cooloney> rsalveti: yeah, i need to compile it in our server
<rsalveti> cooloney: http://bazaar.launchpad.net/~beagleboard-kernel/+junk/2.6.35-devel/annotate/head:/patches/defconfig
<rsalveti> cooloney: I tried one time merging the usb and musb stuff, but didn't get it to work
<rsalveti> so it must be something else
<cooloney> rsalveti: yeah, i also tried that, set the usb and musb config as the same as those in beagle_defconfig
<cooloney> but doesnot help
<rsalveti> cooloney: you can try to trace the code, with debug activated, from the version that works
<rsalveti> and then compare with the version that doesn't work
<rsalveti> the state tracing is easy to see inside the code
<rsalveti> cooloney: yep, for some reason the otg state changes from one config file to the other at the point you put the cable in
<rsalveti> the path to set it to a_idle is simple, the question is why the checking failed and it got into that path
<cooloney> rsalveti: exactly, looks like there is no power on the OTG port
<cooloney> rsalveti: so it never change to the right a_host mode
<cooloney> and failed to enable roothub to enumerate USB device
<rsalveti> yep
<cooloney> rsalveti: i am also comparing the defconfig from you with our Maverick config
<rsalveti> cooloney: ok, I'm now looking again what I need to have for the zippy 2 support
<rsalveti> our kernel is missing lots of patches, it seems
<GrueMaster> NCommander: http://paste.ubuntu.com/466880
<cooloney> rsalveti: could you please help me to post the dmesg which is from the OTG working Maverick kernel?
<cooloney> rsalveti: i think you cross build it with the working defconfig
<rsalveti> cooloney: just the dmesg?
<rsalveti> cooloney: just a sec, need to change the uImage
<cooloney> rsalveti: oh, the uImage is the better. hehe
<cooloney> rsalveti: np, man
<rsalveti> cooloney: http://rsalveti.net/tmp/test-kernel.tar.bz2
<rsalveti> cooloney: you can find the uImage, uInitrd, modules and dmesg.txt
<rsalveti> from the working maverick kernel
<rsalveti> cooloney: if you still didn't compile it
<cooloney> rsalveti: thanks a lot, man
<cooloney> rsalveti: i saw this in the dmesg
<cooloney> musb_hdrc musb_hdrc: MUSB HDRC host driver
<cooloney> [    0.933654] musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 2
<cooloney> [    0.934417] hub 2-0:1.0: USB hub found
<cooloney> [    0.934448] hub 2-0:1.0: 1 port detected
<rsalveti> cooloney: yep, the otg recognized that it should act as host, and activated the host modue
<cooloney> that's we want
<rsalveti> cooloney: yep
<rsalveti> cooloney: and with this kernel I'm unable to reproduce the stack we have with lucid
<rsalveti> so it seems to be working better
<furibondox> hi rsalveti... I tryied your new release of rootstock from bzr ( rev 104) but I have the segmentation fault with qemu again :-(
<rsalveti> furibondox: more than one time?
<furibondox> yes
<rsalveti> argh
<furibondox> every time I run rootstock I have the segmentation fault
<rsalveti> furibondox: what packages are you giving by default?
<furibondox> ubuntu-minimal,openssh-server
<rsalveti> furibondox: did you run as root or as user?
<furibondox> as root
<cooloney> rsalveti: yeah, for the otg oops, i am pretty sure we need to build int twl4030_usb
<furibondox> from ubuntu lucid server
<rsalveti> furibondox: what ubuntu version are you running?
<furibondox> 10.04
<cooloney> rsalveti: and the OTG host failure is another problem.
<rsalveti> cooloney: yep, sure
<rsalveti> furibondox: that's really weird, as I saw it break just a few times when running as root and installing a small package set
<rsalveti> furibondox: does it also break when you just request ubuntu-minimal?
<rsalveti> that will avoid the apt-get install phase
<furibondox> it breaks in the second stage
<rsalveti> furibondox: yeah, I know, and probably when trying to give apt-get install on the openssh-server
<rsalveti> furibondox: do you have the log?
<furibondox> just after python-support
<rsalveti> furibondox: you can paste it at paste.ubuntu.com and set me the link
<furibondox> ok
 * rsalveti needs to update rootstock to run only as user mode emulation when running as root
<rsalveti> that would avoid this kind of weird full emulation stuff, until we get qemu fixed upstream
<furibondox> http://paste.ubuntu.com/466907/
<furibondox> that is the log generated
<furibondox> this is the output of the error in the console: http://paste.ubuntu.com/466909/
<rsalveti> furibondox: what's the whole command line you passed to rootstock? going to check here
<furibondox> ./rootstock --fqdn NGP --imagesize 2G --seed openssh-server --copy-package-cache --restore-package-cache
<rsalveti> furibondox: why do you want to copy and restore at the same time?
<rsalveti> furibondox: you can just copy one time and later you can use restore if you need it
<rsalveti> going to test here, but it should work fine
<furibondox> just to be sure that if some packages are not already present they will be cached
<rsalveti> furibondox: yeah, but it shouldn't make much difference for a basic image, but ok :-)
<furibondox> yes I know... but it was just to be sure ;-)
<rsalveti> furibondox: please, try giving a user and a password argument
<rsalveti> than the oem stuff is not going to be installed by default
<rsalveti> and you'll probably be able to get your image without seg faults
<rsalveti> --login ubuntu --password ubuntu
<rsalveti> something like that
<furibondox> ok i try
<furibondox> rsalveti: now it seems to stop earlier...
<furibondox> start: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
<furibondox> just a moment that I paste the log...
<furibondox> http://paste.ubuntu.com/466920/
<furibondox> and this is the output of the console: http://paste.ubuntu.com/466921/
<rsalveti> furibondox: yep, but it did finish correctly
<furibondox> mmm I thought that error compromised the generated image
<cooloney> rsalveti: do you know where can i find the initrd.gz after i build a kernel package which contains zImage
<furibondox> rsalveti: the error appear again using username/password http://paste.ubuntu.com/466941/
<rsalveti> furibondox: this log is telling that rootstock is installing the oem stuff, and that only gets installed when you don't put the user/passwd
<rsalveti> I: Enabling firstboot configuration
<rsalveti> ^
<furibondox> this is the full log generated http://paste.ubuntu.com/466943/
<furibondox> I'm going to lunch
<furibondox> see you later... bye
<rsalveti> furibondox: still, it seems that didn't got the user/passwd
<rsalveti> if [ ! "${NEWUSER}" ] || [ ! "${PASSWD}" ];then install oem stuff
<rsalveti> furibondox: see ya
<rsalveti> cooloney: you mean, inside the package?
<cooloney> rsalveti: i don't think i can find it in the package
<furibondox> re
<furibondox> rsalveti: now I try with this command line:
<furibondox> ./rootstock -f NGP --username spot --password gilbarco --seed openssh-server,ubuntu-minimal -i 2G --serial ttyS2 --doswap --swapsize 256 --script /root/setup.sh --restore-package-cache
<furibondox> same error: ./rootstock: line 360:   967 Segmentation fault      qemu-system-arm $QEMUOPTS -append "${APPEND}" > $QEMUFIFO 2>&1
<rsalveti> furibondox: --login not --username
 * rsalveti still needs to change how rootstock parse it's arguments
<slangasek> ogra_cmpc: can you tell me what offset I need to loop mount the correct partition in the 20100719 daily image?
<slangasek> my naive calculation based on fdisk -l output seems to have been incorrect
<slangasek> ogra_cmpc: n/m, sorted it; works better when I use sectors as units
<lool> slangasek: Perhaps you can kpartx it?
<slangasek> lool: nah, sorted
<ogra> yeah, sectors helps
 * ogra has some livecd-rootfs code ready to shove off 2h buildtime just waiting for a lamont signoff
<ogra> that might help a bit with building test images
<ogra> slangasek, btw, i wouldnt mind if we started building base images, would that help you ?
<ogra> (in parallel to the netbook ones)
<slangasek> don't see that it would help
<ogra> k
<sebjan> hrw: hi! I tried to apt-get upgrade the gcc-4.4-arm-linux-gnueabi package, and get an error because the libmpfr4 'is not installable' (I have a i386 workstation). Any idea what is going on?
<furibondox> rsalveti: argh! sorry... now I try with --login
<rsalveti> furibondox: yep, np, there's a bug on the way it's parsing the arguments
<rsalveti> normally it should display you an error when you give a wrong arguments
<furibondox> i hope that now it will work...
<furibondox> rsalveti: great! it generates the image!!
<rsalveti> furibondox: cool
<furibondox> I've another question for you, is possibile to ADD another repository to the default?
<furibondox> -m option only replace the mirror or add a new mirror?
<rsalveti> furibondox: yep, --extra-mirror
<furibondox> great!
<furibondox> I'll try
<hrw> sebjan: hmm...
<hrw> sebjan: 4.4.4-7ubuntu1~ppa2hrw1 version?
<hrw> sebjan: and pastebin me whole installation output
<sebjan> hrw: ok, let me do that...
<robclark> persia: MMC hang fix patch is: http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commit/6c8d7209371b5969ea6769382693019ef6cb5eb5
<robclark> (I don't know if it is in ubuntu kernel yet)
<sebjan> hrw: here it is, and ensuring the proper version (which is the one I see with an apt-cache show) http://ubuntu.pastebin.com/YqiGpzBa
<hrw> sebjan: strange
<hrw> apt-cache policy libmpfr4 tells that this is in main
<hrw> sebjan: and try with aptitude - it has better dependency solving
<rsalveti> 15 minutes for resizing an 8gb sd card, seems ok
<rsalveti> just missing a progress bar :-)
<ogra> yeah
<Marex> zumbi: hey
<Marex> XorA: hey ... so, when and where does the drinking take place :)
<sebjan> hrw: not better - http://ubuntu.pastebin.com/06wwXfmS
<sebjan> hrw: is there a simple way to clean-up all the previous packages I installed (I may have been playing with dpkg when there packages were first available, and did not upgrade since then)
<hrw> sebjan: run aptitude, limit to .*-armel-cross and remove all of them
<sebjan> hrw: apt-cache search or policy does not find libmpfr4 for me...
<zumbi> Marex: hi
<hrw> sebjan: maverick?
<sebjan> hrw: no I am on lucid
<Marex> zumbi: don't tell me you're in prague too
<zumbi> Marex: no, i am not :)
<Marex> zumbi: pity :)
<zumbi> Marex: did you get a new toy?
<hrw> sebjan: http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/
<Marex> zumbi: what new toy ?
<Marex> zumbi: you mean the one I was speaking last week ? yea
<zumbi> Marex: the one we were talking about..
<hrw> sebjan: I do not provide packages for <lucid
<lag> mythripk: ping
<Marex> zumbi: and Eric gave me an akita and made me (forcibly) a new maintainer for that
<hrw> I mean <maverick
<zumbi> Marex: akita? what's that?
<hrw> omg.. akita
<Marex> zumbi: there are so many of them I barely recall which one was that :)
<hrw> zumbi: sharp zaurus sl-c1000
<zumbi> hrw: thanks :)
<Marex> zumbi: pile of crap hardware loaded with crap software
<hrw> zumbi: pxa272/416MHz 64mb ram, 128mb flash
<sebjan> hrw: argh, so I would need to upgrade to Maverick now? It used to work with the previous version I had :'(
<hrw> antique
<hrw> sebjan: you can use chroot
<sebjan> hrw: right, I'll try with chroot then. Thanks!
<hrw> sebjan: I was aksed about lucid packages before but rejected - it takes too much time to build maverick ones
<hrw> and my goal is to have package which will build cross compiler. but that would require maverick packages
<sebjan> hrw: np, I shall have a maverick chroot already, just need to upgrade it :)
<hrw> ;D
<zumbi> Marex: uhm... well.. sounds like fun :)
<Marex> zumbi: yea ... not really ... I'm slowly reaching the point where I'll have so many machines I won't be capable of maintaining them all
<hrw> Marex: know that...
<hrw> Marex: have spare not needed palmos device?
<Marex> hrw: I have a palm lifedrive here ... it was still running palmos yesterday
<Marex> hrw: why ?
<hrw> just asked to know do you still play with them
<Marex> hrw: yea, I maintain them in mainline
<Marex> hrw: but I'm moving to newer hardware ... pxa3xx stuff and soon iMX
<hrw> imx3 or imx5?
<hrw> or maybe imx6? :D
<Marex> hrw: I dunno ... lemme check
<Marex> i.MX25
<sebjan> robclark, persia: this mmc fix (6c8d7209371) is not yet into the ubuntu kernel, but is part of the patch set that I have provided to cooloney today
<persia> sebjan: Thanks for chasing that down.
<zumbi> Marex: which device?
<Marex> zumbi: something that still haven't left the manufacturing it seems :D
<Marex> zumbi: I don't know the details yet ... I just know this board is in planning
<zumbi> Marex: but imx25 is old
<zumbi> well, i guess it has its use
<cooloney> sebjan: yeah, thx, i'm looking at your branch
<sebjan> persia: no pb, I just saw a commit pass by, and I care of getting all the necessary ones in our kernel :) Feel free to notify/ping me when there is a doubt
<Marex> zumbi: I wasnt looking into imx yet ... I will when I have the board
<zumbi> Marex: imx5, i had a NDA datasheet of 5000 pages.. fun! :)
<cooloney> rsalveti: how do you think we firstly built-in twl4030_usb in kernel to kill the oops
<cooloney> rsalveti: and mark the OTG config bug as fixed, and file another bug to let us work on the host mode issue
<rsalveti> cooloney: didn't you change the config file to let it as built-in already?
<rsalveti> the kernel you posted on the bug
<rsalveti> cooloney: also, the bug was reported for lucid, so we still need to check at lucid if that fixes the problem
<cooloney> rsalveti: yeah, i did that for testing, the patches are not in our official kernel tree
<cooloney> i am going to do that,
<cooloney> i think we need built-in that, and enable OTG
<rsalveti> cooloney: yep, but I tested your testing kernel at lucid and it didn't work
<rsalveti> the ops was gone, but as a side effect the host mode don't work anymore for otg
<rsalveti> so it actually doesn't fix the bug
<rsalveti> we can't say we're fixing something when we're removing features :-)
<rsalveti> cooloney: but I agree we should create a different bug
<rsalveti> cooloney: I can do that from my beagle
<cooloney> rsalveti: i agree, we need a different bug.
<rsalveti> cooloney: will create it soon
<rsalveti> let me just boot maverick again
<cooloney> but for the oops, we can still mark that Fix, since when we got oops, the host mode does not work at all
<cooloney> we can point it out to the new bug in OTG config launchpad log
<rsalveti> cooloney: yeah, but some times it does work
<rsalveti> most of the time when you add the cable later on
<rsalveti> so just changing the config file will kill this "feature"
<rsalveti> we go from something that works sometimes, to something that doesn't work at all
<cooloney> yeah, so new bug for the host mode missing
<cooloney> rsalveti: and the old one is a oops fixing.
<cooloney> now it looks to me like some timing issue.
<rsalveti> cooloney: just opening the bug right now
<cooloney> rsalveti: ok
<hrw> I hope that one day libelf-dev libelf0g-dev conflict/transition will be done
<ogra> NCommander, cn you bump https://edge.launchpad.net/ubuntu/+source/update-notifier/0.103ubuntu1/+build/1883485 a bit higher ?
<ogra> (so i can test the image build speedup (its bocking atm))
<ogra> *blocking
<rsalveti> cooloney: bug 608312
<ubot2> Launchpad bug 608312 in linux (Ubuntu) "Usb host mode on OTG doesn't work on Maverick with BeagleBoard (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/608312
<cooloney> rsalveti: thanks a lot, man
<rsalveti> np
<tgall_foo> packages.ubuntu.com/lucid as it stands doesn't include any notation of arm which packages are built for arm ...  is there another webpage or command line tool where one can see a list of what is built for arm?
<rsalveti> tgall_foo: do you want something like http://ports.ubuntu.com/ubuntu-ports/pool/main/?
<rsalveti> there are lots of arm packages over there
<tgall_foo> rsalveti, was hoping there might be something like packages.ubuntu.com that listed arm packages instead of having to pull down the individual package text files from like : http://ports.ubuntu.com/dists/maverick/main/binary-armel/
<rsalveti> tgall_foo: oh, ok
<rsalveti> you can try from the repository itself, but I don't think it's on-line in any other way
<rsalveti> at least I never saw it
<ukleinek> tgall_foo: the packages files are easily parsed using grep-dctrl
<tgall_foo> ukleinek, yeah I'm probably being picky .. it's not like text files are hard to deal with
#ubuntu-arm 2010-07-22
<rsalveti> rcn-ee: haha, you just need to load g_ether!
<rsalveti> dammit
<rsalveti> bug 608312
<ubot2> Launchpad bug 608312 in linux (Ubuntu) "Usb host mode on OTG doesn't work on Maverick with BeagleBoard (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/608312
<rsalveti> then the OTG works as expected
<rsalveti> at your config file you have this as built-in
<rsalveti> well, time for some sleep now :-)
 * rsalveti -> out
<rcn-ee_lpt> good to hear rsalveti (yeah the musb stuff is very fragile, one little thing will kill it.. ;) )
<cwillu> long day
<hrw> morning
<XorA> morning
<rsalveti> cooloney: I updated the otg bug, take a look at it later
<lag> Morning mythripk
<XorA> is there a list of supported omap3/4 machines?
<ogra> XorA, not yet since the kernel team is still looking into patces
<ogra> *patches
<XorA> hehe, suck it and see
 * XorA would love zoom3 and 4430sdp :-D
<ogra> XorA, safe bets are panda, beagle C4/XM and blaze
<ogra> blaze will need some tinkering with the bootloader on the image
<XorA> hey vincent
<ogra> i plan to provide a script that replaces u-boot and MLO with the ones you want for a target, the kernels should be generic enough to run on all the platforms
<XorA> that reminds me, wonder if u-boot for 4430 supports nand yet
<ogra> given that there are no devices with NAND, why would anyone enable it ?
<XorA> ogra: no devices with nand????
 * XorA has a deskful of devices with nand
<ogra> 4430sdp with NAND ???
 * XorA thought it did
 * XorA has his hand hacked image on 4430
<cooloney> rsalveti: exactly, sorry for not syncing with your
<cooloney> rsalveti: i tried build in the g_ether into the kernel
<cooloney> the musb hub will be found
<rsalveti> cooloney: that will work, but I don't know if this is the "right" solution :-)
<rsalveti> don't know if building g_ether as built-in is going to affect something else
<cooloney> rsalveti: yeah, because, i found there are 2 place to usb_add_hcd(musb_hcd)
<cooloney> rsalveti: 1 is in host only mode
<rsalveti> yep
<cooloney> 2 is in the OTG mode and gadget init code
<cooloney> but the gadget init code will be only called by the gadget upper level class driver when it start
<cooloney> rsalveti: i tried the compile the musb as host only controller
<cooloney> rsalveti: it works now
<cooloney> at least host function
<rsalveti> cooloney: but why do you want as host-only?
<cooloney> rsalveti: because i wanna test the usb_add_hcd was called in the first method
<cooloney> rsalveti: when i built-in the g_ether, musb hub was found, but usb host function does not work
<rsalveti> cooloney: works when you put the otg cable, at least for me
<rsalveti> cooloney: both gadget and host mode starts to work fine
<cooloney> rsalveti: ok, got it.
<rsalveti> cooloney: if you just change the g_ether as built-in everything should work just fine
<cooloney> rsalveti: so for summary, if we wanna use the host mode of musb, we need to modprobe g_ether, right?
<rsalveti> cooloney: then we need to check if the same modification works for lucid
<rsalveti> cooloney: currently, yes
<cooloney> rsalveti: yeah, yeah, that's what i want to do.
<cooloney> rsalveti: but it failed, it makes me frustrated
<rsalveti> cooloney: because loading g_ether will initialize the gadget and host functionality of the otg chip
<cooloney> rsalveti: exactly,
 * cooloney nods to rsalveti and shakes hands with rsalveti 
<cooloney> rsalveti: ok, let me try again.
<rsalveti> cooloney: ok :-)
 * rsalveti still needs to get a working lucid environment
<User1> Is rootstock about to make a lucid rootfs?
<Jameswstubbs> ogra ?
<Jameswstubbs> able*
<Jameswstubbs> It keeps failing at the second stage
<rsalveti> Jameswstubbs: yes, you can create a lucid rootfs with it
<rsalveti> Jameswstubbs: what kind of failure? qemu seg fault or just got stuck while doing the second stage?
<Jameswstubbs> Stuck during second stage
<Jameswstubbs> Well, when starting second stage
<Jameswstubbs> You might be interested in this actually, ixproject.org :)
<Jameswstubbs> My problem is my karmic rootfs uses an old synaptic module
<Jameswstubbs> I tried to add the lucid repo to the karmic apt and tried to update the module, but got a fatal kernel panic
<Jameswstubbs> I've decided to maybe try lucid, should still be compatible with armv6 shouldn't it?
<GrueMaster> Jameswstubbs: No, Lucid and future releases are armv7.
<cooloney> rsalveti: good news, i build in g_ether this time, it works
<rsalveti> cooloney: cool
<rsalveti> Jameswstubbs: please paste the rootstock log at the paste.ubuntu.com and send me the link
<cooloney> rsalveti: but it looks like a design issue, i think the usb_add_hcd should be called in the early init code, not in the late init code in gadget
<rsalveti> Jameswstubbs: it all depends on how you're running it, as we have these 2 known issues
<rsalveti> cooloney: yep, that's what I think
<cooloney> rsalveti: it is stupid to get host function by insmod a gadget class driver or build in it
<rsalveti> cooloney: haha, for sure :-)
<cooloney> rsalveti: give me sometime to write a patch
<rsalveti> cooloney: that's why I was so mad yesterday
<cooloney> rsalveti: haha, yeah, i was totally frustrated by that as you did
<rsalveti> cooloney: cool, take your time to write the proper patch and send it to linux-omap
<rsalveti> most of the musb maintainers are looking at that list
<Jameswstubbs> Ok, isn't armv7 backwards compatible with v6?
<Jameswstubbs> I'm installing a netinst of ubuntu lucid now
<Jameswstubbs> I'll have to rerun rootstock then paste the log
<GrueMaster> Jameswstubbs: armv7 is backards compatible hardware wise.  But don't expect an armv6 system to run armv7 software.
<Jameswstubbs> Hm, if lucid is indeed completely unsuitable for armv6, how would I go about upgrading the xserver-xorg-input-synaptics.
<Jameswstubbs> If I find the source code for the latest version
<Jameswstubbs> And compile from within my karmic rootfs in qemu, would that work?
<Jameswstubbs> Are the modules architecture dependant ?
<GrueMaster> Jameswstubbs: What exactly are you trying to do?  If you are running Karmic on armv7 hardware, then it is possible to  upgrade to Lucid.  But if your hardware is armv6 only, it won't work.  Like trying to run x86_64 software on a Pentium.
<Jameswstubbs> I'm porting ubuntu to the iPhone, I have a karmic rootfs fully up and running with wifi, xorg and xfce
<Jameswstubbs> ixproject.org if you want a screenshot
<Jameswstubbs> Having a look at my xorg logs, the iPhone multitouch screen uses a synaptic module
<Jameswstubbs> But then says it cannot find a support touchpad
<rsalveti> Jameswstubbs: if you build it at Karmic it should work fine
<Jameswstubbs> pastie.org/1054947 from line 192 down
<rsalveti> it's just that Lucid compiles everything for armv7 by default
<GrueMaster> I'm a little familiar with ixproject.org.  Unfortunately, the hardware just won't run software compiled for the new architecture.  You can pull the source for the latest archive and rebuild it, but our stack is designed for armv7 starting with Lucid.
<Jameswstubbs> I only started ixproject last week :S Maybe familiar with idroidproject
<Jameswstubbs> GrueMaster: I think that's what I'll do
<rsalveti> Jameswstubbs: you could get stuff from debian if you like, it's armv5 compatible
<Jameswstubbs> I'll hunt down the source and compile from within qemu
<Jameswstubbs> The iPhone is armv6
<GrueMaster> Best of luck on your endeavours.
<Jameswstubbs> I've had a debian armel rootfs running happily
<Jameswstubbs> I simply like Ubuntu :)
<GrueMaster> Debian is still armv4 iirc.
<Jameswstubbs> Thanks GrueMaster, I've needed luck up to now and I'll keep needing it
<GrueMaster> heh.  :)
<Jameswstubbs> GrueMaster: I simply used multistrap with debian squeeze
<Jameswstubbs> Worked a charm
<rsalveti> cool
<Jameswstubbs> I have someone working on USB drivers aswell
<Jameswstubbs> Should hopefully have USB host mode running soon
<cooloney> Jameswstubbs: awesome, love your work,
<Jameswstubbs> Thank you :)
<cooloney> although i've sold my iphone and switch to N1
<Jameswstubbs> I hope to have touch sorted within a week and a release should be out soon
<cooloney> but if Ubuntu is ready for iphone, i will grab my girl friend's iphone and force her switch to Ubuntu for iphone
<Jameswstubbs> I don't blame you N1 is an awesome phone, only reason I'm still using iPhone is becasue Im stuck in contract for another year
<Jameswstubbs> cooloney: I wouldn't recommend it immediatley, it wont be ready for prime time
<Jameswstubbs> It needs stripping down and made more mobile friendly
<Jameswstubbs> Im think of using thje matchbox window manager
<cooloney> Jameswstubbs: yeah, fully understand. i am waiting for iphone4 too, and practicing the holding style suggested by Jobs
<Jameswstubbs> Also power management needs to be implemented, the battery wears down in less than 2 hours :/
<cooloney> Jameswstubbs: so how about the kernel in your Ubuntu iphone image
<cooloney> Jameswstubbs: is the kernel from planetbeing?
<Jameswstubbs> Yep, a couple of small changes concerning USB gadget
<Jameswstubbs> But essentially the stock kernel
<Jameswstubbs> The kernel is not in the image, it's stored on the "host" partition and chainloads the rootfs using initrd
<Jameswstubbs> Havn't been able to get initramfs working with the kernel
<Jameswstubbs> Not sure why
<Jameswstubbs> I have a 40 second boot anyway, so It's not a massive concern
<cooloney> Jameswstubbs: yeah,
<cooloney> Jameswstubbs: so is the Ubuntu image only for 3GS or older machine
<Jameswstubbs> We don't have an iboot exploit for the 3gs yet, so development hasn't even started hardware wise
<Jameswstubbs> This is for the 2g and 3g
<Jameswstubbs> I don't own the 2g so havn't been able to test :-/ the only difference is in how the firmware is loaded by the initrd.
<Jameswstubbs> I'm off, thanks for the help :)
<lag> mythripk: I'm back
<hrw> apw: bug 608674 and bug 603087
<ubot2> Launchpad bug 608674 in linux (Ubuntu) "provide packaging rules in linux-source binary package (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/608674
<ubot2> Launchpad bug 603087 in linux (Ubuntu) "Allow to build just linux-libc-dev (affects: 1) (heat: 270)" [Wishlist,In progress] https://launchpad.net/bugs/603087
<ogra> rsalveti, dd if=/dev/zero of=livecd.${FSS}.ext2 bs=1024 count=0 seek=$size
<ogra> rsalveti, size=$(($(du -ks ${ROOT} | cut -f1) + (10240)))
<lag> ogra: What monitor do you have? The one that _just works_
<ogra> lag, samsung syncmaster T240
<lool> ogra: Hey, did you folks change from .bz2 to .gz recently for omap images?
<rsalveti> vstehle: robclark: http://maemo.gitorious.org/fremantle-hildon-desktop/clutter_0_8
<rsalveti> the call is EGL_NOKIA_texture_from_pixmap
<rsalveti> at clutter/eglx/clutter-eglx-texture-pixmap.c
<robclark> rsalveti: thx
<davidm> lool, yes
<davidm> lool, bz2 is BAD with rsync, .gz works with rsyncing images
<furibondox> hello everybody
<furibondox> now I'm definitely able to run the image from the rootstock!
<furibondox> but I've some problem with udev and mmcblock and mtdblock... udev does not create the device for the partition automatically...
<furibondox> anybody has a similar problem?
<ogra> lool, yes, bz2 wasnt rsyncable, gzip has the special flag to make the files usable with rsync
<orbarron1> hey all.. I am trying to bring up ubuntu on Blaze (OMAP4) using http://www.omappedia.org/wiki/Get_started_with_ubuntu_on_omap4 but it is locking up at boot up has any one seen this?
<lool> ogra: But doesn't it contain a filesystem?
<ogra> lool, sure, whats the issue with that ?
<lool> ogra: Well filesystems aren't very rsync friendly across runs
<lool> I have the issue with cloud images
<lool> they almost don't compress with rsync, despite being built with gzip --rsyncable
<ogra> i didnt test to zsync yet
<ogra> since we only have one image thats gz yet
<ogra> we'll see if there is improvement once i could test :)
<furibondox> guys, anybody have problem with ubuntu lucid and udev for the automatic creation of /dev/mmcblk0p* and /dev/mtdblock* devices?
<cwillu_at_work> nope, works fine here
<orbarron> Hey guys... just to let you know OMAPpedia is having a tutorial hour next week covering Uboot and Ubuntu. Visit: http://www.omappedia.com/wiki/Main_Page. The time may be a bit late for some of you but we are trying to find a good time for everyone. orga will be a guest speaker for this session. If anyone is interested in doing a session in Aug. please ping me :D
<furibondox> I've created a lucid minimal image with rootstock but when the system starts, I don't see any /dev/mmcblk0p* and /dev/mtdblock*
<rsalveti> furibondox: are you able to see the other devices that are created by udev?
<furibondox> yes
<rsalveti> furibondox: what kernel are you using?
<furibondox> 2.6.29
<rsalveti> furibondox: from where?
<furibondox> the same kernel works fine with a jaunty distribution created by my own
<furibondox> from TI PSP
<furibondox> I think the problem is with the udev and lucid
<furibondox> http://paste.ubuntu.com/467568/
<furibondox> as you can see the partitions are present... but udev does not create the device!
<rsalveti> furibondox: could be a bug with udev with this kernel
<furibondox> may be...
<furibondox> this is what I see: http://paste.ubuntu.com/467569/
<rsalveti> furibondox: you could try to debug udev, to see what it detects normally in your case
<lem_> hi, I am trying to install ubuntu karmic on bb using the method specified in http://elinux.org/BeagleBoardUbuntuKarmic , it boots the kernel,after login and password I get stucked with a prompt
<lem_> there is any command to install from there?
<tgall_foo> lem_, personally I'm using linaro's alpha2 on my bb -  https://wiki.linaro.org/Source/ImageInstallation
<ojn> tgall_foo: hardly on-topic in this channel.
<lem_> thanks for the idea, I will try that
<tgall_foo> ojn: given the amount of maverick packages in it, it's fairly on topic ;-)
<lool> ojn: Hey, just curious, are you doing some upstream kernel OMAP work?  are you doing that on top of Ubuntu?
<ojn> lool: I'm not doing much omap work these days. I've spent more time with tegra lately. And no, given my new project and employer, I am not doing much on top of ubuntu. :)
<ojn> omap is still around as a side project, but I haven't spent any serious cycles on it lately
<lool> ojn: Oh, which employer is that?   :)
<ojn> lool: I'll leave that as an exercise for the reader. :)
#ubuntu-arm 2010-07-23
<Baybal> fd
<tmzt> can somebody tell me what the dropped patches to xorg-xserver are, specifially 111_armel-drv-fallbacks.patch, are
<hrw> hi people
<robclark> gm hrw
<Baybal> hi
<lag> Morning
<Baybal> evening
<tmzt> ok, found it, it seems to be related to dove
<JamesWstubbs> Hello
<JamesWstubbs> Looking for some advice if that's ok, basically I'm using a Karmic rootfs and need to update xorg to it's latest version. I've tried adding Debian squeeze repo's and installing xorg, but I had too many dependency errors, I'd fix one and be presented with another. Anyone got any ideas of how to update xorg to the latest version on Ubuntu 9.10 on armv6?
<lag> Sounds more like a Ubuntu issue, rather than an Arm specific one
<JamesWstubbs> It's arm specific because I can't upgrade to lucid.
<JamesWstubbs> Also I can imagine I'll be dealing with arm repo'
<JamesWstubbs> s
<lag> ogra: --^
<ogra> there is no easy solution
<JamesWstubbs> Lucid requires armv7 I'm using armv6
<tmzt> lag: backports for armv6vfp don't exist for current packages
<tmzt> I've had this same issue and have found no solution
<JamesWstubbs> It being hard won't be a problem, I've been working on with this for a while already
<ogra> either recompile the debian packages or recompile the lucid packages and pray that you can get all deps and build-deps right
<lag> Or upgrade to a supported board?
<ogra> right
<JamesWstubbs> What if I don't need all of xorg, I only actually need xserver-xorg-input-synaptic to be upgraded
<JamesWstubbs> lag: It's for the iPhone, I can't upgrade for another year :)
 * lag <- Is impressed :)
<ogra> well, try to rebuild xserver-xorg-input-synaptic from the lucid source package, though i would assume there are versioned dependencies you need to backport as well
<ogra> are you 100% sure the synaptics driver will work on the iphone HW ?
<ogra> did you try something like tslib ?
<JamesWstubbs> ogra: It's interesting, someone called ikex created a debian port but never released, from the few notes he left his xorg worked out of the box with the touchscreen. After checking my xorg logs I see that the touchscreen hardware is loaded, it then tries to load the synaptics module, but then reports it can't find a suported touchpad, I checked the squeeze armel repo and it uses 1.2.2 where as Ubuntu karmic repo uses 1.1.2, I'm making the assumption m
<JamesWstubbs> ogra: I've tried tslib, lib-ts, evtouch and mutouch
<JamesWstubbs> Will xorg.conf's written by hand
<JamesWstubbs> I've had no luck.
<JamesWstubbs> With*
<JamesWstubbs> Also, did you write rootstock ogra, if so I'd like to credit you when I release.
<ogra> i wrote it, rsalveti is maintining it now
<JamesWstubbs> Thanks, I've written his name down
<JamesWstubbs> lag: I don
<JamesWstubbs> 't want to spam this channel, you might be interested in this, ixproject.org
<lag> JamesWstubbs: I've seen it
<JamesWstubbs> Ah
<lag> JamesWstubbs: We've spoken before
<JamesWstubbs> Sorry, probably hasn't been progress since :)
<JamesWstubbs> I'm going, going to try compile from source, see what that does.
 * XorA still wishes ubuntu was multi arch on arm
<ogra> we'll be muli omap at least at some point :)
<hrw> XorA: multiarch...
 * XorA has some nice armv5te hardware
<ogra> use linaro on that :)
<XorA> hehe
<hrw> XorA: multiarch is not about armv5/6/7/4 etc
<hrw> from what I understood
<ukleinek> there are two similar problems on ARM.  One is using different generations in a single image (like armv5 vs. armv6)
<ukleinek> the other is about compiling omap and imx in a single image
<ogra> shudder
<XorA> hehe
 * XorA would just love to be able to standardise on one distro
<ogra> linaro is working on that
<ogra> might take some years though
<ogra> NCommander, https://edge.launchpad.net/ubuntu/+source/livecd-rootfs/1.142/+build/1886888 bump please
<ogra> robclark, https://bugzilla.gnome.org/show_bug.cgi?id=624082 and bug 569273
<ubot2`> Launchpad bug 569273 in indicator-application (Ubuntu Maverick) (and 6 other projects) "memory leak in gnome-power-manager on lucid (affects: 39) (dups: 1) (heat: 237)" [Medium,New] https://launchpad.net/bugs/569273
<ubot2`> Gnome bug 624082 in gnome-power-manager "GPM memory leak on amd64" [Major,Resolved: notabug]
<ogra> NCommander, chroot probs, i gave back livecd-rootfs, can you bump https://edge.launchpad.net/ubuntu/+source/livecd-rootfs/1.142/+build/1886888 gain ?
<ogra> *again
<rsalveti> robclark: just fbset -i should show you more information
<rsalveti> robclark: just install the fbset package
<rsalveti> dyfet: fuseext2 -o ro,direct_io
<dyfet> ah...
<lool> ogra, NCommander: ping
<NCommander> lool: contentless pong detected.
<lool> ogra, NCommander: I'd like to requeue packages which didn't build due to qt4-x11 being broken
<lool> NCommander: Eh I was still typing!
<NCommander> lool: already started doing so
<lool> NCommander: So you're taking care of it?
<NCommander> lool: I'm waiting for qtwebkit-source to finish building so I can start retrying the KDE stack
<armin76> NCommander: ping
<NCommander> lool: yup
<NCommander> armin76: yet another contentless ping detected
<armin76> NCommander: ping!
<NCommander> YACPD :-P
<armin76> unping :P
<lool> NCommander: how many FTBFSing packages are involved with qt4-x11 in your estimates?
<NCommander> lool: a lot :-/
<NCommander> ~10-15 in main, and a bunch more in universe
<armin76> lool: hows qt-x11 broken?
<NCommander> armin76: compiler ICEs, thus resolved
<lool> armin76: gcc-4.4 was borken and couldn't build qt4-x11 anymore
<lool> NCommander: Sounds like a good win to have the qt4-x11 stack on armel!
<armin76> lool: have bug no?
<NCommander> lool: I still need to unbreak kdebindings since upstream broke my code
<lool> armin76: maybe https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/603602
<ubot2`> Ubuntu bug 603602 in gcc-4.4 (Ubuntu) "ICE building qt4-x11 on armel (affects: 1) (heat: 529)" [High,Confirmed]
<lool> Yes that's the one
<lool> NCommander: Hmm apparently you filed a duplicate
<XorA> NCommander: your who I think you are right, across the table from me?
<rsalveti> mpoirier_: http://rsalveti.net/tmp/beagleboard.tar.bz2
<rsalveti> mpoirier_: have fun and let me know if you find the issue
<mpoirier_> rsalveti: cool thanks.
<rsalveti> np
<rsalveti> dyfet: I'd suggest you to do some testing on the fuseext2 stuff while creating the documentation for it
<rsalveti> dyfet: what you can do is to get some rootfs like and mount it, try to read from it (creating tarballs), checking the size of the tarball
<dyfet> I did at the time...but not on very large file sets
<rsalveti> also, try to write something, edit a config file, something that a normal user would do
<rsalveti> and see if it works
<rsalveti> dyfet: yep, stressing it would be a good thing to do
<dyfet> I will try what you did to stress it, yes...
<rsalveti> nice
<GrueMaster> http://www.asylum.com/2010/07/22/its-the-worlds-strongest-most-expensive-beer-inside-a-squi/
<ogra> NCommander, and another bump please, https://edge.launchpad.net/ubuntu/+source/linux-meta-ti-omap4/2.6.35.902.3/+build/1887035
<lag> ogra: http://paste.ubuntu.com/468042/
#ubuntu-arm 2010-07-24
<tim> hi ... i've got a sharp netwalker z1 and would like to upgrade the version of ubuntu (it comes with 9.04 preinstalled). after a simple update, it does not boot any more, though ... the device is using redboot as boot loader ... before starting a new attempt, does anyone have experience with this device?
<tim> also, is there some kind of live-microsd image? sharp just provides an image, that restores the original state of the machine ...
<Baybal> eh
<Baybal> what kind of upgrade you did?
<Baybal> nikulinpi@gmail.com
 * Baybal away
<tim> Baybal, adapt /etc/apt/sources.list to point to lucid and sudo apt-get dist-upgrade
<Baybal> hmm
<Baybal> did you update kernel?
<Baybal> I think you may have pointed the apt to repository for PC
<Baybal> I'm sleepy
<Baybal> email me please
<Baybal> i'm gonna go bed
<tim> Baybal, ok ... i'll send you an email ... i guess, the kernel was updated ...
<tim> mc
<persia> tim: Hey: I've a PC-Z1 also.  The issue is twofold: 1) it's hard to find any newer kernels for that device, and 2) it ships with Ubuntu for ARMv5, but lucid is for ARMv7+thumb2, which means one needs to essentially reinstall (and compile a new kernel with the lucid toolchain).
<tim> persia, hm ... see
<tim> persia, did you manage do to that?
<persia> Do which?  Upgrade?  I've not found a newer kernel.
<tim> i see
<tim> btw, what specifics does the kernel have?
<persia> My understanding is that lucid udev, upstart, etc. require features not available in the older kernel.  I've not tried it with the mix, but I wouldn't expect it to work.
<persia> How do you mean, what specifics?
<tim> certain device drivers etc
<tim> the source, that is provided by sharp is essentially the 2.6.28 vanilla kernel
<persia> Oh, I don't know the specifics.  The source is available: let me see if I can dig it up.
<persia> I'm certain the provided source is the real source.  I know there were some patches that got sent upstream.  I don't know if all the patches got sent upstream.
<persia> Any of the "araneo" sources at http://netbook-remix.archive.canonical.com/updates/pool/public/l/linux-fsl-imx51/ would be the correct source for the packages installed on the machine.  I think the sendai kernels are for the newer netwalker (without keyboard).
<tim> ah ... i see ... btw, i just checked ... there _are_ some differences between the vanilla kernel and the sharp kernel
<tim> i will try, maybe i can port them to a recent kernel version
<persia> If you can, that would be *great*!  I'd love to run lucid or maverick on the PC-Z1
<tim> persia, i'll do my best ... do you know of any source, how to cross-compile a kernel?
<persia> I only know a little about how the kernel packages are compiled, but the kernel team usually hangs out in #ubuntu-kernel, and they can probably answer anything that doesn't get a good response here about how the package works (I think the contents are from Sharp or Canonical or someone, so I wouldn't expect the kernel team to know them well).
<persia> We generally discourage cross-compilation in Ubuntu.  I seem to remember some document on the kernel team wiki about cross-compilation, but I don't remember the URL.
<persia> You might do a text search on the wiki (but it will take a while).
<tim> persia, i'll try ..
<persia> I've just asked in #ubuntu-kernel, in case anyone knows, but those guys tend to be quiet on the weekends.
<tim> btw, do you know, if there is a git respority for the araneo sources?
<persia> I don't know.  I heard some rumours that it wasn't developed in git, so if there is, and the rumours are true, the git repo would be more of a back-application of patches.
<tim> hm ... i just found an interesting forum posting from someone, trying to port it to 2.6.31 ... and who gave up because of badly written code :(
<persia> :(
<persia> http://ime.nu/kernel.ubuntu.com/git?p=amitk/ubuntu-fsl-2.6.31.git;a=summary might have some of it, according to http://pc11.2ch.net/test/read.cgi/linux/1258005134/
<persia> Well, you might want to fix the redirect on kernel.ubuntu.com :)
<tim> persia, hm ... true ... not easy to port :/
<persia> That's what everyone tells me :(
 * persia hopes someone will make some new small PC that runs Ubuntu well and works with upgrades.
<tim> not easy doesn't mean, not impossible
<tim> s/im//
<cwillu> honestly, mainline kernels work fine for the most part
<cwillu> i.e., unless you actually have hardware that we include the driver for
<persia> cwillu: You're able to boot a mainline kernel on a PC-Z1?  I was advised this might melt my laptop.
<tim> cwillu, i guess, there is some specific hardware in the machine ... almost 400000 lines of code differ between vanilla 2.6.28 and sharp's
<cwillu_at_work> (sorry, ran off)
<cwillu_at_work> and I missed the bit about non-standard hardware too :p
<persia> I'm not sure it's "non-standard", but just not known to be supported mainline today.
<persia> It's certainly widely available in retail channels though.
<cwillu_at_work> I haven't had my coffee yet, give me a break :)
<persia> Sorry: timezone failure :)
 * cwillu_at_work checks the time
<cwillu_at_work> oh, it's even morning
<tim> hm ... if we would know, what the original version of the kernel was, that sharp was modifying, it would be easier :/
<persia> I suspect it's the 2.6.28 BSP from FSL, but I can't be sure.
<tim> well, it conflicts with very early version of 2.6.28 from the linux-2.6-imx.git tree ... then the sources diverge
<persia> Ugh
#ubuntu-arm 2010-07-25
<lool> ogra: Around?
<ogra> partially
<ogra> whats up ?
<lool> ogra: I grabed the latest preinstalled image for omap
<lool> and tried to run it under qemu
<lool> it failed as usual
<lool> but I found a way to get it working
<ogra> likely broken due to kernel out of syncness
<lool> it's related to the fat filesystem in the first partition
<ogra> oh ?
<lool> ogra: I compared with a working Angstrom image, and while the disk partitioning was okay, the fat looked different
<ogra> the only thing that might differ from angstrom wrt first partition could be the mkdosfs binary or sfdisk
<lool> ogra: First, note that the disk partitioning says it's a fat32 (type 0xc), but your images actually contain a fat16
 * ogra checks debian-cd
<lool> ogra: Second, I'm not entirely sure that just setting things to fat32 is enough; mkfs.dosfs apparently has a concept of heads, and I strongly suspects it might behave differently on real devices versus files
<lool> ogra: If that is an option, I'd like if we could switch the omap3 images to fat32 to start with, but that will require testing again on all target hardware platforms
<ogra>     echo ,9,0x0C,*
<ogra> thats from the sfdisk scripts from tools/boot/maverick/post-boot-armel+omap
<ogra> copied from the angstrom build script
 * lool bzr upgrading his debian-cd checkout
<ogra> i'm fine switching to anything you like as long as it doesnt break
<ogra> we just need to keep jasper in sync
<ogra> since it recreates the first partition on first boot
<lool> ogra: if we discover the format is not the only one you need to support, it might make sense to have jasper read the current format to create a new one
<lool> ogra: So I think the issue is with: mkdosfs -C $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1
<lool> ogra: this needs -F 32, otherwise the format is selected automatically depending on the size of the fs, and ends up being FAT16 here
<ogra> hmm, jasper uses "/sbin/mkdosfs -n "SERVICEV001" -F 32 /dev/${DISK}${SEP}1"
<ogra> seems debian-cd is just behind here
<ogra> i need to sync the commands
<ogra> jasper also uses ",$SIZE_P1,c,*" in sfdisk
<ogra> instead of capitalized C
<ogra> not sure if sfdisk interprets that any different
<lool> ogra: Perhaps what would make sense is an omap-utils package which we would eventually be able to install in initramfs + on antimony, and then call exactly the same commands?
<lool> e.g. with a "create-boot-vfat" script and such
<ogra> hmm
<ogra> i would rather tie it to jasper than to the subarch
<ogra> but yes, that sounds like a good idea
<lool> ogra: Clearly the concept of special vfat partitions is specific to OMAP
<lool> but you could have a jasper-utils package which has an omap-create-boot-vfat script  :-)
<lool> ogra: I'll open an ubuntu-cdimage bug to track the above issue
<ogra> something like that
<ogra> assign it to me
<ogra> i'm not really sure you actually want to run these images in a vm though
<ogra> since you have no actual disk hardware that at least requires some extra preparation
<lool> ogra: Why wouldn't I have disk hardware?
<ogra> i.e. making sure to create the image file big enough
<ogra> the image is self expanding, there is nothing you can resize to unells you first create a bigger image into which you dd the downloaded .img file
<ogra> *unless
<ogra> makes running in in a vm a bit more complex
<ogra> its nopt that its impossible to use it that way, but its not designed to be run without preparation in a vm
<lool> ogra: That's ok, I understand
<ogra> i should probably add a little more spare space like 500M or so, so it can run without resizing too
<ogra> gzip should just compress it it away for the gzipped image
 * ogra will play with that
<lool> ogra: I personally find it a waste that you'd do that
<lool> I can deal with this downstream
<ogra> well, it wont affect the download size, likely speed up the ultra slow resizing and make it possible to actually run oem-config even if resizing failed
<lool> ogra: It will affect the time it takes me to unpack and the space it will take unpacked
<ogra> thats true, though it would also be a good way to enforce minimal specs like using 4G cards (by adding enough empty space to not fit on a 2g card anymore)
<lool> ogra: So, I've posted a bug with a proposed (untested) patch; it affects OMAP4
<ogra> change implemented on antimony
<lool> LP #609700
<ubot2`> Launchpad bug 609700 in ubuntu-cdimage "OMAP pre-installed image uses FAT16 partitions (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/609700
<ogra> oh, you added a patch ?
 * ogra checks
<ogra> nearly the same as my change (my option ordering is slightly different)
<lool> ogra: Would you assign yourself to the bug and close it if you merged that already?
<ogra> lool, if the archive ever gets in sync again, please test the next image in qemu, i'll test panda and beagle
<ogra> i dont want to close it before we tested it both
 * ogra mentions the change 
<ogra> set to inprogress
 * ogra goes for food
<lool> I've filed LP #609706 for the qemu counterpart of this issue
<ubot2`> Launchpad bug 609706 in qemu-maemo "QEMU ROM emulation code doesn't cope with FAT16 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/609706
#ubuntu-arm 2011-07-18
<siji> Hi
<siji> am trying to install xbmc on ubuntu-arm
<siji> which is giving some errors like
<siji> The following packages have unmet dependencies:
<siji>  xbmc : Depends: xbmc-data (= 2:10.1~ppa1~maverick) but it is not going to be installed
<siji> am running natty , since there is no xbmc build for natty , added maverick path for XBMC installation
<infinity> siji: If that's from the team-xbmc PPA, they don't have any packages built for armel.
<infinity> siji: So, the arch:all xbmc package won't be able to find any arch-specific dependencies.
<siji> infinity, http://ppa.launchpad.net/team-xbmc/ppa/ubuntu/dists/maverick/main/
<siji> this is my sourcelist entry
<siji> infinity, then how I have to proceed ?
<infinity> siji: Yeah, that PPA doesn't build for armel.
<siji> oh ok
<infinity> siji: You could donwload their source packages and build them yourself.
<siji> infinity, i have already started it
<siji> infinity, but that ppa weblink showing that armel package is there
<siji> (while opening from browser)
<infinity> siji: You'll note that the "Packages" file for armel only has the arch:all packages in it.
<infinity> siji: Which is less than useful for you.
<siji> oh ok
<siji> Now am trying to build xbmc on natty
<siji> and getting some ./configure error
<siji> checking boost/shared_ptr.hpp usability... no
<siji> checking boost/shared_ptr.hpp presence... no
<siji> checking for boost/shared_ptr.hpp... no
<siji> anyone can tell me a solution ?
<siji> Fixed :)
<siji> hi all
<siji> XBMC is giving sme errors while doing make
<siji> pls have a look into the log at http://pastebin.com/9d1JY5h2
<siji> persia, you there?
<siji> (Os:natty ,hardware ;Beagleboard)
<siji> here the config.log http://pastebin.com/DjuFFmig
<LetoThe2nd> siji: sounds like a missing dependency, such as *guess* libgles-dev or such
<siji> LetoThe2nd, libgles is already there
<LetoThe2nd> siji: also the corresponding -dev package?
<siji> got it..Checking
<siji> I think dev package is not there
<siji> LetoThe2nd, I have refered this doc for installing gles https://wiki.ubuntu.com/ARM/OMAP/Graphics
<LetoThe2nd> siji: this page syas absolutely nothing about xmbc, so i doubt a bit that you are referring it very closely :P
<LetoThe2nd> siji: but basically, missing .h or .hpp file are nearly always due to some missing -dev package.
<siji> LetoThe2nd, ok
<LetoThe2nd> siji: background: the -dev packages contain the header files that are necessary for linking to the corresponding libs when compiling manually. i'd suggest to have a look on some documents about compiling on ubuntu/debian in this context.
<siji> LetoThe2nd, thanks
<LetoThe2nd> siji: this one looks good: https://help.ubuntu.com/community/CompilingEasyHowTo
<LetoThe2nd> siji: step 3 is exactly your topic. i _suggest_ you have a good look at it :)
<siji> LetoThe2nd, am familiar with those
<siji> here the problem because of ARM and the various OMAP drivers
<LetoThe2nd> siji: no, missing .h files are exactly what step 3 describes....
<siji> LetoThe2nd, ok
<siji> persia, you there?
<slavanap> What type of arch should I select? http://paste.org/pastebin/view/36244
<slavanap> if I have (armv4l) str8132 arch ?
<LetoThe2nd> slavanap: are you trying to run ubuntu on an amrv4?
<LetoThe2nd> slavanap: as for the selection - make sure your target has kernel support. might be you need to apply some board support patch
<slavanap> LetoThe2nd,  I'm trying to build the kernel for ubuntu. Now I have debian with old kernel there, sources of that kernel I also have.
<LetoThe2nd> slavanap: just rebuilding the kernel won't get you far.
<LetoThe2nd> slavanap: ubuntu ist armv7
<slavanap> LetoThe2nd, and in the old kernel I have str8132 support, but not in a new one.
<LetoThe2nd> slavanap: then probably your old kernel is patched and your new one not.
<slavanap> LetoThe2nd,  Where can I ask how to extract patch from old kernel and apply it to new one?
<LetoThe2nd> slavanap: ask those who gave you the old kernel. they obvisouly have the patches.
<infinity> slavanap: I know you've been told this before (a few times), but you realise that Ubuntu's userspace (ie: everything after the kernel boots) won't work on your machine, right?
<LetoThe2nd> slavanap: i can only also teel you again: ubuntu will not work on that machine, even if you have the kernel patch. the userland is armv7. and it will stay.
<slavanap> LetoThe2nd, ok. i se..
<slavanap> *i see.
<slavanap> LetoThe2nd, then Gentoo is my choise.
<slavanap> LetoThe2nd, thank you for help.
<LetoThe2nd> have fun then.
<Neko> anyone know of a decent PPA for armel builds of Firefox?
<micahg> Neko: we don't have a native PPA for the milestone builds yet, which ones are you looking for?
<Neko> Firefox 5 for Maverick.. there's a firefox team PPA for other arches but no armel builds
<prpplague> rsalveti: ping
<rsalveti> prpplague: pong
<prpplague> rsalveti: hey i am trying to clean up the pandaboard repos on gitorious. i can not delete the repo until all the clones are removed. would you mind removing the one you have?
<rsalveti> prpplague: let me check
<rsalveti> prpplague: I'm trying, but seems gitorious is slow when removing repos
<prpplague> rsalveti: indeed
<rsalveti> and boom: 503 Service Unavailable
<prpplague> rsalveti: it removed it
<rsalveti> prpplague: cool
<rsalveti> prpplague: any other repo to remove?
<prpplague> rsalveti: nope thats plenty!
<rsalveti> great
<prpplague> rsalveti: thanks
<martyn1> Is anyone here working on EDAC on Arm?
<neko> ugh.. natty on pandaboard, why did I even bother?
<neko> anyone know of any slightly newer preinstallation SD images?
<GrueMaster> oneiric Alpha 2.
<GrueMaster> Or if you want absolute bleeding edge, there are the dailies.
<GrueMaster> http://cdimage.ubuntu.com
<neko> what if I don't want to run buggy broken Oneiric
<infinity> So, you want newer than the latest stable release, but you don't want a development release? :P
<neko> yeah I kind of want.. like how Lucid had a 10.04.1 release that was significantly better :D
<infinity> We don't do point-releases for non-LTSes.
<infinity> Well, not as a rule.
<neko> the whole idea was it ran a semi-stable distro and not one in constant alpha, but the stable one doesn't work even though it's "officially supported"
<neko> and it seems everyone just said "WONTFIX" and moved to Oneiric
<infinity> For the record, my Panda runs natty just fine...
<neko> how do you get past this loop of oem-config running constantly
<infinity> It... Doesn't?
<neko> this is my 5th time through.. I have a valid user, hostname is set up
<neko> it said "warning: GTK cannot open display .0" for about 10 seconds and then started oem-config again
<infinity> And that's natty, not an oneiric daily?  I've never seen that on natty (not that I don't believe that the bug is there, mind you)
<infinity> But I'm not sure what to say, other than perhaps I'm lucky.
<neko> maybe my SD card is way too expensive? :D
<infinity> I did a headless install (went fine) and a desktop install (also fine) on natty, and the machine is now a buildd over there *waves to his right*.
<neko> I am just gonna kill off /var/lib/oem-config/run and reboot
<persia> I've not seen that even with Class 10 SDs and the special 4-channel Class 6 SD that was supposed to be super-extra-fast
<neko> I really only got it so I could build packages on it for the efikamx
<neko> also to see how fucking awful a board it might be (and yes, it's a shitty design... confirmed! :)
<neko> I miss my beagle..
<neko> for all it's flaws, rcn-ee's little rootstocks always worked great on it
<persia> !ohmy > neko
<ubot2> neko, please see my private message
<neko> now I have a storage-less dual core with wireless.. eh.. I dunno.. buyer's remorse I guess
<infinity> w/win 20
<neko> did the ubuntu-omap4-extras ppa move?
<persia> I heard that TI hadn't fully populated it for natty.  I may be mistaken.
<neko> rsalveti, nudge?
<rsalveti> neko: hey
<neko> rsalveti, you seem to maintain pvr-omap4 and so on, I noticed on installation it removes all the mesa stuff
<neko> how on earth did you manage that safely? we'd love to do the same on MX51
<rsalveti> neko: you just need to do the conflict/replace/provides correctly
<neko> hmm, we tried that, packaging system went haywire complaining about it
<rsalveti> you can check the source package for both pvr-omap4 and omap3, they both do it the same way
<neko> that may have been around Karmic/Lucid though maybe mesa is less "fidgety" these days?
<rsalveti> during old days I believe this was handled by update-alternatives
<rsalveti> if you copy the packages from the omap4 one, it'll work the same way
<rsalveti> just use apt then, as it'll need to solve the conflicts
<rsalveti> dpkg will complain
<neko> hmm yep.. Provides/Conflicts/Replaces for our stuff is exactly the same.. I notice one bug though (typo in our openvg control..)...
<neko> hang on I thing I'm gonna give this a kick
<jeramee> hi guys
<jeramee> I am kinda new to ARM
<persia> jeramee, Hey.
<persia> jeramee, Unless you have very specific needs, it's about the same as everything else, except the hardware is different.
#ubuntu-arm 2011-07-19
<jeramee> yeah
<jeramee> I finally got a Qemu going and installed development packages in it
<persia> Cool!  What are you building?
<jeramee> and also I hacked a board I got from best buy installed the development package and wrote a few minor programs
<jeramee> lol
<jeramee> really
<jeramee> I would like to make a touch screen puppy linux distro
<jeramee> but maybe just use it for logging sensor and i/o streams
<jeramee> and control a robot
<jeramee> 800 mhz is plenty enough brains to clean my kitchen floor and maybe mow the grass
<jeramee> lol
<persia> Well, we can't help much with Puppy here, but robots are fun.
<jeramee> especially because it is RISC
<jeramee> are you really from Persia?
<jeramee> yeah Puppy is nice distro and in my opinion would be great on tablet PC etc
<jeramee> the newest is 125 mb
<jeramee> the old school is like 98 mb and less
<persia> I'm not from Persia, and I'm of the school of thought that calling a place "Persia" just reinforces an old insult.
 * persia respects the concept of "Persian", which is completely different
<persia> (and no, I'm not Persian either)
<jeramee> full gui, burn CDs , stream music etc
<jeramee> you do not need like gigs and gigs and gigs to do stuff lol
<persia> Not at all, although I believe that all the distributions are about the same in terms of requirements.
<persia> The useful question to ask about distributions is: which gives you the development environment you find comfortable?
<jeramee> Gnome
<jeramee> lol
<jeramee> not Ubuntu
<persia> As someone who does native development (yes, even on the beagleboard), I like Ubuntu.
<jeramee> straight Gnome
<persia> I'm talking about the lower-level tools.
<persia> I thought the bug that kept one from running regular GNOME in Ubuntu was fixed.
<jeramee> and XFCE deserves honorable mention
<persia> If not, it ought be.  THere's bundles of folk who prefer GNOME Shell to Unity, and they ought be able to do as they like.
<jeramee> it is
<jeramee> and runs smooth
<persia> We do XFCE just fine.  LXDE as well.
<jeramee> I love XFCE just idk not easy to arrange stuff lol
<jeramee> and some stuff still compatibility issues
<jeramee> but doubt I will move to Unity
<jeramee> so XFCE or Xubuntu I see those as future
<persia> Heh, that's fine.
<jeramee> lol
<jeramee> seems like browsers, OS, etc, etc
<jeramee> all make more bloat so you need better hardware lol
<persia> In this channel, we tend to be concerned about the few things that make ARM special, and making sure all the packages in the archive work properly on ARM targets.  Specific desktop choice, etc. we leave to users.
<jeramee> when will enough be enough
<jeramee> so do Desktop fully compile?
<jeramee> cause really command-line is all you need for many things
<jeramee> but just curious
<persia> I know of folk using kubuntu-desktop, lubuntu-desktop, ubuntu-desktop, and xubuntu-desktop on armel.
<jeramee> wow
<jeramee> nice
<persia> I don't know of anyone using ubuntustudio-desktop on armel, but I suspect that works as well.
<jeramee> yeah I am on studio atm
<jeramee> running gnome
<jeramee> and my slow PC has XFCE
<persia> I don't know if anyone tested either of the edubuntu desktops, or the packages therein, but there's a good chance they work.  I had reports that Mythbuntu might not work so well, but no bug reports or specific complaints, so I can't be sure.
<jeramee> yeah one thing I hate about XFCE is real bad media playing
<jeramee> flash, etc
<jeramee> but hey when you sit down to program no need to stream videos on Youtube lol
<jeramee> just curious though
<persia> Hrm?  I thought the media stuff got fixed.
<jeramee> I ran all the patches
<persia> And Flash shouldn't be different for different flavours of Ubuntu: we all use the same implementation.
<jeramee> all the updates
<jeramee> it doesn't crash
<jeramee> system or player
<jeramee> just seems a bit more choppy
<jeramee> tried XFCE and Xubuntu
<jeramee> same result
<jeramee> so any of these distro's have touch screen functionality
<jeramee> ?
<persia> I thought parole was cleaner than that, but each person's experience may differ.
<jeramee> well I am running 10.4 with RTAI
<jeramee> so maybe makes a difference
<persia> Ubuntu has touchscreen support, and so that is available for all flavours.  Precisely which applications take full advantage of that, and which just consider it as an X pointer, is more complicated (and building an exhastive list is likely impossible: things change faster than one can usefully test that many thousands of applications)
<persia> Oh, yeah.  Media *production* works well with RT.  Media playing tends to work poorly with RT.
<jeramee> wow good to know
<jeramee> lol
<jeramee> so you can build them better just not watch
<jeramee> lol
<jeramee> no wonder studio runs so smooth
<jeramee> lol
<jeramee> i dont even use it to make movies lol
<jeramee> aren't some ARM OS RTOS
<jeramee> like kernals?
<persia> That's a software thing, independent of the hardware.
<jeramee> was thinking maybe that would be better for automation
<persia> We don'T have any realtime kernels in Ubuntu currently, so Ubuntu can't be configured as RTOS (although you could presumably create your own, if you want to forward-port the RT stuff, and we'd gladly use it if it was available).
<persia> Depends on your needs.  If you need that level of timing control, it's better.  For most folk, most of the time, there's no point.
<jeramee> lol
<jeramee> compiling my own kernel is one thing
<persia> I've seen folk get submillisecond reactions from things without RT, but sometimes there are scheduling bumps, and one ends up with 10s of ms.
<jeramee> building lol
<jeramee> is another
<jeramee> yeah well technically
<persia> For cleaning your kitchen, <100ms latency is likely to be fine, unless you have very expensive fragile cabinets, and a heavy robot with no padding.
<jeramee> RTAI would be fine
<jeramee> if all you are doing is talking to Microcontrollers
<jeramee> they could keep the timing
<jeramee> for you
<persia> Oh, so you have your RTAI system that handles movement, cleaning, etc., and then your Ubuntu system that provides instructions, touchscreen, network access, etc.?
<jeramee> nah not there yet
<jeramee> but maybe I will try to build something of that nature
<neko> how do I make my omapfb use a decent display mode after I install omap4-extras
<neko> omappedia and elinux wiki are useless as is the ubuntu wiki... it seems like they're repeating very old info which isn't relevant as of today
<persia> I thought we fixed the EDID issue: did that fix not get adopted in that PPA?
<neko> I can't even find half these sysfs attributes it talks about, and nothing I edit boot.script to do seems to actually take effect (although /proc/cmdline reflects them, which is nice)
<neko> I have absolutely no idea
<neko> if I plug it into the edge HDMI port I get zip
<jeramee> like for instance, real nice CNC machines have touch panels for calibration etc, and also another food for thought is I have 5 PC, plus 1 ARM.  Dedicate 1 to house automation, walk in room touch make coffee on the arm  and clean kitchen etc
<neko> if I plug it into the HDMI port next to the USB slot I get 640x480
<neko> which is nice. with pvr it runs like a hellcat
<neko> I'd just rather it did 1600x900 like my monitor says it can do (and my efika supports nicely if I swap cables)
<neko> the big pixels make my head hurt :D
<persia> neko: Have you played with get-edid and parse-edid?
<neko> never heard of them and a quick check confirms: not installed
<neko> also, /sys/class/graphics/fb0 has no edid properties and nor does /sys/devices/platform/omapdss/whatever/in/here
<persia> You'd have to install read-edid.  There's some stuff inside X that also does it, but I don't beleive the user interface to be as pleasing.
<persia> That sounds like an EDID error then.
<neko> X doesn't do anything
<neko> what do you mean an EDID error
<neko> omapfb sucks and cannot read from the i2c bus, or.. you're assuming I have a busted monitor?
<persia> Failure to accurately collect EDID over HDMI, parse it, and set the screen correctly.
<persia> I doubt the monitor has an issue, because you say it works with another device.
<persia> I suspect either that there's an issue collecting the EDID with the current software stack *OR* that there's a failure to use the EDID data once collected.
<neko> I tried 11 monitors, all of which work fine and report fine on the efika mx (and I get native res, or 1080p or 720p) - but every single one dumps to 480p. I can't imagine why it would not work on omap...
<neko> all the wiki pages say there is some wicked awesome hdmi hotplug and edid grabbing stuff in sysfs and it's simply not there
<neko> it's like, it's an old driver or something
<persia> So, verify that you can get and read the EDID data.  If you can't, file a bug about that.  If you can, file a bug about not using the EDID data.
<neko> 2.6.38-1208-omap4 seems to me to be totally brand new though
<neko> eh I installed read-edid and .. nothing is installed? what am I meant to be running?
<neko> problem here is I have no idea what I am looking for yet
<persia> get-edid and parse-edid
<neko> so a bug report is going to be totally useless
<neko> get-edid: command not found
<persia> Check your path.  If you installed the read-edid package, it should be in /usr/sbing/get-edid
<persia> s/bing/bin/
<neko> pfft, nope.
<neko> I got lots of getkeycodes, getopt stuff but no get-edid anywhere
<persia> Does `dpkg -L read-edid` show you a useful location?
<neko> I just pulled in read-edid 2.0.0-3.1 which to my mind only works on PCs anyway
<neko> even building it for armel, traditionally, has been a waste of cpu cycles... however someone could have added omap stuff to it in the past aeon :D
<neko> so far I see nothing
<neko> parse-edid is installed
<neko> it needs a file as input. as I said nothing in sysfs...
<persia> Right, that's what get-edid is supposed to output.
<neko> yeah I think you are thinking of some other more awesome tool
<neko> read-edid hasn't been updated since 2009 and I am damn sure nobody ever made it read edids from anything other than VESA BIOS calls or from /proc/device-tree
<persia> No, but I'm relying on received hearsay that the framebuffer support got added, and am installing it on a natty/armel system in parallel to test for myself
<neko> maybe I am using release of omap4-extras when I should be using trunk?
<persia> I heard that "release" was the software TI wanted everyone to use, and "trunk" was where TI was doing their development work.  As a result, I suspect "trunk" of being unstable.
 * persia gets annoyed at read-edid, and tries to figure out why it's broken
<neko> well, compiling read-edid's "get-edid" part would be useless on anything but x86 or ppc or sparc right now
<neko> and even if you got linux fdts on armel, it wouldnt have edid data in it, u-boot is too stupid to glue the data in
<neko> so you have to assume the data is, like any reasonable driver, in /sys
<neko> (it is on the efika, on any PC with a radeon.. comes in really handy)
<persia> IS that how X's EDID parsing is implmented?
<neko> no, X asks DRM CRTC for it
<persia> And that gets it from?
<neko> or, I should say, X asks the driver, and the driver implements a CRTC, which is usually hooked into a DRM CRTC on the kernel side
<neko> it gets it from whatever i2c bus or whacked out method the HDMI controller or so implements
<persia> Aha.  That makes sense.
<neko> most of 'em just let you read address 0x50 on i2c and it passes the data back
<persia> So I suppose what I really want to do is to have X expose this in some useful way, rather than fixing read-edid
<neko> on the sii9022 on efika and mx53_loco, you have to ask the sii9022 for it
<persia> (and I should stop relying on read-edid to be useful)
<neko> X can't know unless the kernel knows
<neko> the kernel, here, doesn't know
<neko> which makes me think, super-old kernel, or simply super-broken kernel...?
<neko> it probably works great on oneiric doesn't it
<persia> There's a /usr/bin/decode-edid in i2c-tools, but if you're correct about i2c being nonfunctional, that won't help.
<neko> maybe it just needs a backport
<neko> well.. I dunno if there's anything nonfunctional
<neko> I simply know that glued to the framebuffer driver, on the omapfb side of things, it has a little driver on i2c which is run after framebuffer is initialized, which would read edids, set the controller up for all manner of fancy stuff (like hdmi audio) and put them in a nice place
<neko> that's just the only way to do it unless you're a DRM driver in which case, stuff gets reaaaally fancy and they have a slightly less braindead solution for it that is more like X does it
<persia> Ah, but that's *after* framebuffer initialisation, so we already have a resolution.
<neko> in any case, I don't see any dmesg output that says it has a monitor attached, it doesn't even parse my kernel commandline
<neko> and that i2c driver can set whatever resolution it likes
<neko> I spent enough time in the ipu3 framebuffer getting the sii9022 to work on the efika to know how it usually works.. and I've seen the omapfb code
<neko> however, what is on this pandaboard right now.. doesn't seem to be the code I saw... it seems to be much, much older
<neko> like May last year kind of older
<persia> What's the last entry in the changelog for the package that provides it?
<neko> uhh Bryan Wu, * [Config] Update to 2.6.38.2 kernel config and other changes
 * persia grumbles at binaries without manpages
<neko> 2.6.38-1208.11
<neko> April 4, 2011
<persia> Hrm.  That isn't quite last year, but that change doesn't look substantive.
<neko> well the package may have been built in April but the actual code doesn't seem terribly up to date
<neko> I think they might have missed a merge window
<neko> what I was looking at that looked workable was like 2.6.39-rc3 or something.. that was way, way after April
<neko> but I assume this stuff gets backported
<neko> I assume wrong :D
<persia> Assumptions are rarely safe.
<neko> as a kernel developer and maintainer, product manager of an arm platform, I usually make pretty reasonable assumptions about what our customers want to see, and to be honest, 640x480 isn't it
<persia> Some code gets cherrypicked, when it fixes a clearly obvious serious bug with little to no chance of regression as SRU.
<StevenK> persia: Speaking of no man pages: http://pastebin.com/gct7GLW9
<neko> that's why I bumped 1080p support into the genesi kernel, and kicked someone to write proper hdmi hotplug support.. it seems someone did that at TI too, it just didn't make it into Natty and nobody updated the kernel in an aeon
<persia> Most backports are just backports entire, in the -backports repositories, but kernels and modules are almost never put there because of the potential for regressions if userspace fails to match kernelspace.
<persia> StevenK: Heh.  Yeah.
<neko> it makes me sad how quickly a release gets abandoned
<persia> neko: Last update in April sounds like there's stuff needing doing.  I suspect there's some security fixes that *should* have been applied.
<persia> If there's a known safe cherrypick to fix some other code, it might be able to get into the same place.
<prpplague^2> neko: s/release/girlfriend
<neko> 4th April is just squeaking in before Natty code freeze..
<persia> Alternately, are you sure there isn'T a new kernel in natty-updates?
<neko> well I spent 5 hours downloading and installing 100MB of new packages for the Panda
<neko> if it was in updates, I downloaded it...
<neko> maybe extras pissed over the top of it?
<persia> neko: No, I have the same kernel as you, and I should also be up to date.
<neko> hmm nope. but there is a unity update being held back
<persia> Someone probably ought prepare an SRU for that, really.
<neko> so I'm updated up to the point I can be updated..
<neko> An effervescing elephant with tiny eyes and great big trunk once whispered to the tiny ear of one inferior that by next June he'd he'd die.. oh yeah! Because the tiger would roam...
<neko> I think Ubuntu missed a trick by not having an Effervescing Elephant release
<jeramee> lol
<jeramee> Effervescing Elephant
<jeramee> well neko any idea how to write programs to utilize touch panel
<jeramee> any good links that you could recommend?
<neko> absolutely not
<neko> I am kind of a low level guy and very high level guy
<neko> applications are inbetween, not my thing
<persia> jeramee, You might take a look at the utouch package.  It is a metapackage that installs several libraries and tools for working with touch and gestures.
<jeramee> nice that is likely all I would need as what I wish to use the touch panel for is not really that sophisticated.  I will check it out thanks for the talk guys.  Now back to circuit design.  Maybe I will full with the ARM some more this weekend.  Is kinda a side hobby.
<jeramee> Nice talking to you guys, afk
<prpplague> jeramee: as long as your touch panel driver is configure for standard events, it will work fine
<persia> Depends what one wants to do, but yeah, for 90% of "touch enabled" applications, standard X pointer events are sufficient.
<prpplague> adding fancy touch buttons and such are that hard
<jeramee> and for double touch use QT seems
<prpplague> doing it as a library or as a generic support, that can get tricky
<jeramee> i had browser going other day
<jeramee> but really need to build X
<persia> What's your processor?  You may be able to just run Ubuntu's X.
<jeramee> does utouch require more than basic X
<persia> jeramee, "utouch" is just a collection of useful libraries for doing touchy stuff.  If your X and your applications use the same libraries, you get fancy stuff.
<persia> If you just want a working touchscreen, that's a driver thing, and X will just do the right thing.
<jeramee> I think it is a freescale
<jeramee> kinda poor documentation
<jeramee> I had a gift card from christmas
<jeramee> and knew I could get 800mhz and 8" for like $35
<jeramee> so was enough to get started
<jeramee> later I will look into a more professional board
<jeramee> Marvellâs Armada 168  any associated build problems?
<persia> The Armada 168 isn't compatible with Ubuntu: we usually recommend Debian for that.
<persia> Freescale's i.MX51x and i.MX53x SoCs should be compatible.
<slangasek> anyone looking at the ghostscript build failure? :)
<persia> slangasek, Apparently not specifically.
<persia> Oh ugh.  Someone sync'd d-shlibs.
<slangasek> clobbering an Ubuntu delta?
<slangasek> yep, apparently
<slangasek> hah, janimo has already identified the fix
<slangasek> a new sync of d-shlibs needed
<persia> Right.
<persia> The d-shlibs patch was always a workaround, and was rightly rejected in Debian Bug #581258
<ubot2> Debian bug 581258 in d-shlibs "d-shlibs: typo of the dynamic load library prevents build-dependent packages from building" [Important,Open] http://bugs.debian.org/581258
<persia> pitti read that, and force-sync'd, without anyone having applied the real fix.
<slangasek> doh
<slangasek> well, syncing for bug #812155 now
<ubot2> Launchpad bug 812155 in d-shlibs "Sync d-shlibs 0.47 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/812155
<persia> Aha, and jonas discovered that Debian Bug #548626 was misfixed, causing the entire mess.
<ubot2> Debian bug 548626 in d-shlibs "glibc-2.10 on armel introduces new dynamic linker and breaks d-devlibdeps" [Important,Fixed] http://bugs.debian.org/548626
<persia> That ought do it.
<persia> 0.47 includes the fix for 633933, which is the reapplication of 548626
<persia> Mind you, I still think that the bug is really in glibc, but if jonas did it the other way, we may as well respect that.
<jeramee> i have problems with glibc sometimes seems kinda buggy
<jeramee> and dmks i think
<jeramee> but resolved as of now
<jeramee> until next time I find something they dont like
<jeramee> seems my processor is running ARMv5 any suggestions on what to install on it
<persia> Debian.
<rsalveti> janimo: bug 812381 and bug 812110 are sync requests to fix arm ftbfs on ubuntu
<ubot2> Launchpad bug 812381 in qutecom "Sync qutecom 2.2.1+dfsg1-1 (universe) from Debian sid (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/812381
<ubot2> Launchpad bug 812110 in klatexformula "Sync klatexformula 3.2.4-1 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/812110
<janimo> rsalveti, I have no syncing powers
<rsalveti> so need to wait an archive admin I believe
<janimo> rsalveti, right, I think it happens daily as there are several adimns shifting
<Spider-Pork> i would to get ubuntu on my gumstix overo fire. Is there a prebuild image?
<infinity> rsalveti: Done and done.
<rsalveti> infinity: great, thanks
<jojo11> hey does anyone know if hardware encoders on BeagleBoard-xM are usable unlike the ones on PandaBoard
<siji> persia, ping
<mahmoh> if I swap out my SD on my panda, is there a way to rescan it like a scsi disk?
<ppisati> have anyone used strace to trace a running process?
<furibondox> hi guys
<mahmoh> where was that bug about USB IO and pinging the ethernet, didn't that get fixed, persia, GrueMaster?  I remember talking about it but I cannot find the bug in question
<GrueMaster> I'm not seeing anything in LP.  I think I read about it on the pandaboard mailing list.
<mahmoh> we were talking about it last week I think
<GrueMaster> mahmoh: http://jeffbastian.blogspot.com/2011/06/storage-speed-on-pandaboard-revisited.html
<GrueMaster> mahmoh: Have you tested this recently?  If not, I'll do a quick spot check to see if the problem exists in 1309.14 and file a bug accordingly.
<prpplague> GrueMaster: it appears to still be present 3.0-rc
<GrueMaster> great.
<prpplague> GrueMaster: it doesn't appear to be  lan9514 related
<GrueMaster> I'm going to file a bug in our tracker so that we can keep abreast of it.  I'm rerunning jeff bastian's benchmark tests to attach to the bug report for our kernel team.
<prpplague> GrueMaster: please detail how you run the test so that i can run them as well
<GrueMaster> Has anyone filed a bug upstream?
<prpplague> GrueMaster: mrcurious has been following the issue
<GrueMaster> Yep.
<GrueMaster> It will be in the bug report.
<prpplague> GrueMaster: i'll check with him when he is back on irc
<GrueMaster> I'll also try to fire up a Maverick install and copy it to a usb drive to see if it exists there as well.  If we can isolate it to a release, we can debug it more readily (in theory).
<GrueMaster> prpplague: Do you remember the kernel cmdline for setting mac address?  I have a couple of pandas (A1 & EA1) that share the same die id (thus the same mac).
<GrueMaster> Save me having to google for it.
<prpplague> GrueMaster: i dont believe upatched kernel support the mac argument
<prpplague> GrueMaster: think you have to apply a patch for it
<prpplague> GrueMaster: check with robclark , he normally has a good patchset for ti
<prpplague> it
<GrueMaster> It is in the natty kernel already.
<GrueMaster> I'll just look it up.
<ppisati> guys, besides janimo, anyone else can test the new ti-omap4 kernel? it's here: http://people.canonical.com/~ppisati/ti-omap4-next/
<GrueMaster> ppisati: Are you aware of this performance bug with USB drives & having to ping the ethernet port?
<ppisati> GrueMaster: heard about it long ago
<ppisati> GrueMaster: still there?
<ppisati> GrueMaster: care to try the new kernel?
<GrueMaster> Apparently.  I am trying the 1309.14 kernel on oneiric now.  As soon as I finish the comparison there, I can.
<ppisati> cool
<ppisati> i tried to fix an audio bug today, but it seems it's a pulseaudio problem
<ppisati> so i won't wait anymore, tomorrow i'll push it
<GrueMaster> ok
<prpplague> GrueMaster: btw, i haven't confirmed it myself, but i was told that the issue presents itself on omap3 boards as well as on some arm9 based boards
<GrueMaster> prpplague: If I get around to it, I can try it on an XM.  It would be interesting to see if it is also present on a beagle C4.
<GrueMaster> sigh.  So many tests, so little time.
<mahmoh> GrueMaster: I think this is the bug on the ping problem - bug 709245
<ubot2> Launchpad bug 709245 in linux-linaro "panda: USB disk IO slow" [Medium,Confirmed] https://launchpad.net/bugs/709245
<GrueMaster> interesting.
<mahmoh> ppisati: you need that kernel tested, what are the fixes that you're looking to verify?
<mahmoh> GrueMaster: 1309-14 - 0.2 MB/s vs. 4.0 MB/s w/ ping flood - the problem still exists, I would say this is higher than Medium too
<GrueMaster> mahmoh: What are you running to produce these results?  We need to document them so that they are reproducible (which I am doing now and will add to the bug report).
<mahmoh> pts/tiobench
<mahmoh> I'm adding a comment to the original bug, and asking to raise the priority too
<GrueMaster> Let me know when you have it filed.  I can raise priority and do other bug triage stuff from there.
<mahmoh> GrueMaster: https://bugs.launchpad.net/linux-linaro/+bug/709245/comments/6
<ubot2> Ubuntu bug 709245 in linux-linaro "panda: USB disk IO slow" [Medium,Confirmed]
<Guest48215> Hi all, I am working with pandaboard trying to get a video conferencing application to be built on it
<Guest48215> I am using ubuntu 10.10 as the 11.04 doesn't seem to contain hardware codecs
<Guest48215> I see the panda board to have HDMI and DVI dual display capability
<Guest48215> It seems like ubuntu 10.10 does NOT support dual display but the ubuntu 11.04 seems to have support...
<Guest48215> Can I get pointer to the dual display patch which I can back port to ubuntu 10.10?
<Guest48215> Please correct me if I am wrong in my assumptions
<GrueMaster> mahmoh: If you test with the new kernel, use my test as it is quicker to setup and runs faster.
<mahmoh> GrueMaster: which test?  I'm testing the new kernel now
<GrueMaster> See comment 7 in the above bug.
<GrueMaster> I also added the linux-ti-omap4 kernel to the bug.  If you reproduce it on the 3.0 kernel let me know so I can add it as well.
<mahmoh> GrueMaster: yeah, the results appear to be the same on the 3.0.0-1 kernel
<GrueMaster> Can you post benchmarks on the new kernel?
<mahmoh> yes I can but it appears that they are the same a with the 2.6 kernel, no change in IO perf.
<GrueMaster> ok
<GrueMaster> Just note in the bug that you tried that kernel and I will add it to the top of the bug report.
<GrueMaster> mahmoh: Check out http://lists.fedoraproject.org/pipermail/arm/2011-June/001412.html
<mahmoh> yep, makes sense
<mahmoh> so the 3.0.0-1 kernel looks ok - boots, runs IO performance fine - I'm running three boards with it and haven't seen any major issues as of yet
<GrueMaster> Still has the USB performance issue though, right?
<martyn> The performance of AoE is just POO on arm
<GrueMaster> martyn: what are you testing with?
<persia> Bug 709245
<ubot2> Launchpad bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed] https://launchpad.net/bugs/709245
<GrueMaster> persia: ??
<persia> GrueMaster, Got a ping asking for a bug number in backscroll.  Wanted to verify the bug.  Seems like you found it already, looking at more backscroll.
<GrueMaster> I'm currently testing to see if it affects Maverick as well.
<persia> That's a neat idea.  Maybe it was introduced at some point, rather than being always present.
<GrueMaster> I hope so.  Might make it easier to backtrack.
<persia> Indeed.  If it was introduced, we can bisect it to the source.
<persia> If it is a bug in the initial implementation, there's no guide to the specific code to be fixed.
<Jack87|Away> anyone consider ubuntu arm on HP touchpad?
<GrueMaster> Jack87|Away: What hardware does it have?
<Jack87|Away> its a snapdargon not omap.
<persia> Ought work, but someone needs to upload a kernel, as there are none supporting snapdragon in the archive.
<Jack87|Away> http://h18004.www1.hp.com/products/quickspecs/14077_na/14077_na.pdf
<Jack87|Away> by the way... they got xserver running as an app.
<Jack87|Away> GrueMaster, check this out... http://yfrog.com/h0galnp
<Jack87|Away> those desktop enviorments are an xapp runnin within the touchpad
<GrueMaster> Cool.
<Jack87|Away> you can see in card view :). I was just wondering if anyone has taken intrest in the device here
<GrueMaster> I've been too swamped, and I have a Nook Color to get running ubuntu if/when I can get some spare cycles.
<Jack87|Away> GrueMaster, hehe me to.
<GrueMaster> Interesting resutls of testing bug 709245 on Maverick.  Not sure that I am doing this right.
<ubot2> Launchpad bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed] https://launchpad.net/bugs/709245
<mahmoh> yes, 3.0.0-1 did not change the USB performance/ping issue
<Neko> I think it's down to the hub chip in use
<Neko> I suggested someone kick around the enhanced TT scheduler and turbo mode on the usb ethernet and it got ignored
<Neko> because it has to be some kind of bug in the omap4, apparently.. and nothing to do with kernel options
<mahmoh> if someone wants to put in the time, I'll test it for sure
<mahmoh> persia: I thought we discussed the USB/ping problem before and someone mentioned that it was fixed in a later kernel - guess not?
<infinity> mahmoh: Probably confusion about USB issues.  We had an issue with no USB at all, that's fixed.
<mahmoh> it's possible
#ubuntu-arm 2011-07-20
<GrueMaster> mahmoh: If you read the pandaboard emails, someone got that confused with the GCC-4.6 usb ehci bug.
<GrueMaster> At any rate, this bug is well documented in LP now.
<GrueMaster> mahmoh: If you have a usb stick & usb drive attatched, can you see how it performs when you have some constant i/o in the background of one while doing benchmarks to the other?  I'm thinking something like "while (1);do dd if=/dev/zero of=<mount point to usb stick> bs=4M count=10;done"
<mahmoh> GrueMaster: I do and I'm sure it'll work but I can try it if you're really curious to find out ;)
<GrueMaster> No, We really should get back to focusing on server tests.
<mahmoh> agreed
<persia> mahmoh, We did discuss it.  It was suggested that some changes were made that would improve things.  The latest results posted seem different than earlier results, so I think the situation is improved.
<arcaico> hello, everyone ! I am trying use "dhclient" in ubuntu-arm (mini6410 board), but I have this problem http://pastebin.com/BW03ucUJ
<arcaico> Someone Can help me?
<persia> arcaico, Which kernel are you using?
<arcaico> persia, Linux FriendlyARM 2.6.28.6-FriendlyARM #2 Sat Jun 26 13:24:08 CST 2010 armv6l GNU/Linux
<mahmoh> ppisati: I ran three pandas overnight with 3.0.0-1 with "heavy" IO and have seen no problems, I did see one problem before that on one of the boards, unsure if it's related or not, http://paste.ubuntu.com/647721/    http://paste.ubuntu.com/647768/
<GrueMaster> arcaico: We don't support armv6.  Ubuntu-arm shifted to armv7 with Lucid.
<persia> arcaico, That's probably the issue then: that doesn't look like an Ubuntu kernel.  Are you sure the options mentioned in the messsage you posted are enabled?
<ppisati> mahmoh: looks like you lost /
<mahmoh> ppisati: hm?  should I write that one up or ?  I have logs too
<ppisati> mahmoh: i already pushed a new kernel on my tree on zinc
<ppisati> mahmoh: care to try that one?
<mahmoh> point me to the deb and I'm all over it as soon as my IO testing is complete (2 hrs or so)
<mahmoh> ppisati: do you think it'll fix my problem above?
<ppisati> mahmoh: don't think so
<ppisati> mahmoh: anyway, 2 things: 1) can you try with the actual oneiric/natty omap4 kernel? 2) how did you get it? is it reproducible?
<mahmoh> ppisati: I hit other problems with the actual kernel, io-usb related
<mahmoh> I can share those with you
<Neko> persia, nudge, where was that pandaboard bug?
<mahmoh> this one? https://bugs.launchpad.net/linux-linaro/+bug/709245
<ubot2> Ubuntu bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed]
<prpplague> Neko: techincally it isn't just panda
<prpplague> Neko: i've been able to replicate the problem on my tegra2 board
<Neko> what does the tegra have between usb host and the port on the board?
<Neko> smsc hub
<Neko> >
<Neko> if it's trimslice it's a USB2514 which is the same thing all told as the one in the Panda.. just the Panda has the one with the built-in ethernet controller
<Neko> I really think it is down to enhanced tt scheduling..
<Neko> for trimslice the ethernet is on a completely different bus so messing with USB shouldn't change any of the behavior of the ethernet stuff which is more scary indeed.. but, for now, I can't find the stupid bug number
<Neko> are you using the usb-to-sata onboard?
<Neko> therefore hammering usb sata makes other usb stuff go faster, or moving the mouse makes usb-sata faster? I'd love to know the effect
<Neko> anyone know what that awesome yet very unfriendly to users way is to basically roll back a git repository to a certain commit on a branch, and force that branch up so that commits are removed and not just HEAD moves around?
#ubuntu-arm 2011-07-21
<smp4488> im trying to get openbox to run on my beagleboard xm. When i start x the screen flickers but the logs are showing no protocol specified
<smp4488> got it! needed to delete all the .Xauthority files in /~
<jeramee> hi guys
<persia> hey jeramee
<mahmoh> ppisati: testing the latest 3.0.0-1~dd and seeing kjournald timeouts with IO tests, unsure if they're new or not
<ppisati> mahmoh: how did you get it?
<cmagina> ppisati: he said he was running io stress tests
<cmagina> one thing i noticed were the usb resets found before the hung task warnings
<ppisati> usb hardisk?
<cmagina> i believe so
<cmagina> ppisati: yeah, it has a usb disk enclosure plugged into an externally powered hub
<ppisati> unfortuntaley it seems usb support is flaky
<ppisati> and it has been like this for a while
<ppisati> e.g. lp 709245
<ubot2> Launchpad bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed] https://launchpad.net/bugs/709245
<ppisati> if you ping the board while doing I/O tests, performance improve
<mahmoh> it's getting pinged now and still seeing the resets
<ppisati> can you try with a natty kernel?
<mahmoh> natty?  I guess, can you point me to a package?  I think GrueMaster confirmed yesterday that he saw it with natty and maverick, the usb ping problem
<GrueMaster> ppisati: I have tested this with a natty image as well as a maverick image.
<mahmoh> I think it makes more sense to crash or dump when the problem occurs so we can see what's actually happening, no?  cmagina?
<GrueMaster> And apparently it has also been reproduced on a beagleXM.
<GrueMaster> It is a problem with either the usb chip or the driver for it.  prpplague has more insight.
<cmagina> mahmoh: doubt it, as the crash would occur ~2 minutes after the usb reset occurred and that is the probable culprit for the hang
<mahmoh> could we lower the timeout and attempt the crash that way?
<ppisati> imo the best thing we can do is a fill a new bug for it (how to reproduce it, logs, etcetc) so we can forward it to more people
<ppisati> TI, usb ml, arm, more people can see it, etcetc
<mahmoh> or throw USB into debug?  what's the best approach here?
<ppisati> but yes, the usb support for all the omap chips so far always had problems
<mahmoh> http://pastebin.ubuntu.com/649155/
<ppisati> uhmmm
<ppisati> updatedb.mlocat? at the same time with an IO test? i bet it's stuck! :)
<mahmoh> what's updatedb.mlocat from?
<ppisati> mahmoh: from your pastebin -> Started Run 1 @ 05:29:28[27121.715026] INFO: task updatedb.mlocat:7519 blocked for more than 120 seconds.
<cmagina> heh, missed that
<GrueMaster> Next time you guys run io tests, you should run "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" first.  That will disable the timeout errors (what you are seeing).
<mahmoh> yep, but what is "updatedb.mlocat", part of the fs?
<GrueMaster> It may have nothing to do with the test suite.  Notice you also have an error in that pastebin from java.
<cmagina> no, updatedb.mlocate generates the index that the locate commands uses
<cmagina> its a cron job
<cmagina> you should disable it
<GrueMaster> No, leave the background tasks alone.  Just run the echo command above.
<mahmoh> it's part of the default system plus we're on a dual core board, it should be fine
<cmagina> its not cpu bound, its io bound
<GrueMaster> we're hitting generic kernel timeouts on panda.  We either disable them (as above) or we change the kernel config.  I suggest manually disabling them first.
<mahmoh> as for the timeouts, those should not occur either, I want to see when they happen
<cmagina> the hung task timeout is just notifying you of the problem
<cmagina> of a problem
<mahmoh> exactly
<cmagina> this could be that the system is thrashing as well
<GrueMaster> Find out what the default timeout is and try increasing it.
<mahmoh> 120s
<GrueMaster> So try doubling it and rerunning.
<cmagina> i would leave it, its not the problem, what we need to know is if we are getting completely hung or if the system is just thrashing under the load and as a result some processes are not getting the time they need
<mahmoh> I'm not tweaking the system at this point except to debug this problem
<mahmoh> so how do we find that out?
<cmagina> we could enable sar data gathering and see if we are seeing high io wait times
<cmagina> not sure if there is an easier way
<mahmoh> hm, it is running the threaded io tests after all, hm, and elevator=deadline
<GrueMaster> Look at your logs and see exactly what test reproduces this, then rerun just that test with different timeout settings.
<mahmoh> ppisati: so this is with the 300-1~dd kernel, but I'm pretty sure it'll happen with stock, should I switch back or push forward?  I'm going to try the same thing on two other boards
<mahmoh> the problem is there's no schedule as to when this occurs but I may be able to force it running background IO tasks (like updatedb.mlocat)
<GrueMaster> mahmoh: I think you are beating a dead horse.  We need to keep moving forward.
<mahmoh> you may be right but if there's a fundamental problem that needs to be fixed then it should be looked at; I can dedicate one board for this and push on on the other ones
<cmagina> mahmoh: 252 is currently hovering around 70% io_wait
<GrueMaster> There is a fundamental problem, but we do not have the resources or time to dedicate everything to it.  Others outside ubuntu are also looking at it.
<GrueMaster> One board is good.  3 is a bit much.
<cmagina> and by adding updatedb, it hit ~90%
<siji> persia, you there?
<GrueMaster> mahmoh: In reply to server kernel question in #u-meeting, there probably won't be a server specific kernel.
<mahmoh>  then install should add a scheduler line to boot, Daviey?
<GrueMaster> I don't know what the differences are on x86, or if they have any affect on armel.  May be worth looking into after Alpha 3.
<mahmoh> sounds like just a bug to me, where should it go if it's against the installer vs. kernel image?
<GrueMaster> It can be added to the server preinstalled images fairly easily I would think.  Not sure about netinstall.
<mahmoh> should be both
<GrueMaster> We should run some benchmarks on it to see if it helps performance on armel.
<Martyn> GrueMaster ; What are the major differences, if any, between the desktop and the server kernel for x86?
<GrueMaster> I know it should be both, just not sure how to go about it with netinstall.
<GrueMaster> Martyn: ENOIDEA.
<Martyn> copy that
<mahmoh> it should install server kernel when selecting Ubuntu Server
<Martyn> I'll take a look at it right now
<GrueMaster> Hence why I raised the question.
<mahmoh> scheduler is diff.
<ppisati> janimo: i couldn't fidn any marvin24 3.x kernel on gitorius
<janimo> ppisati, I think he justs sends stuff to lkml or the tegra list, at least that was my impression
<janimo> are you on #ac100 ?
<janimo> I do not know of a 3.0 kernel of his, just saw him active upstream
<ppisati> yep, i'm on ac100
<mahmoh> GrueMaster: so where should an arm-server-kernel bug request go? and where should a net-install-server bug go?
<GrueMaster> I have no idea.  This is the first server work i have done with Ubuntu.
<mahmoh> it's not server related it's either kernel image related or installer related, where do those bugs live?
<GrueMaster> In launchpad.  beyond that I don't know.
<GrueMaster> File a bug on the kernel for tracking purposes.
<GrueMaster> From there, a comparison should be made on x86, and the relevant bits tested on arm.
<arcaico> Hello, I am using ubuntu linux on SDcard .. my root (/) filesystem is not the total size of the sdcard
<arcaico> my (df -h) is http://pastebin.com/fw6zeG5D
<GrueMaster> arcaico: What image is this ?
<arcaico> Linux FriendlyARM 2.6.28.6-FriendlyARM #2 Sat Jun 26 13:24:08 CST 2010 armv6l GNU/Linux   --- by: http://www.friendlyarm.net/
<GrueMaster> I have no idea what that is or where it comes from.  Not an Ubuntu linux for sure.
 * GrueMaster doesn't even see any references to Ubuntu on their web page.
<arcaico> GrueMaster, http://www.youtube.com/watch?v=mBN0BUWoxa0
<arcaico> http://kanebebe.dip.jp/download/ARM11-6410-DVD/images/Ubuntu/
<GrueMaster> Unfortunately, we dropped support for 9.10 at the beginning of this release cycle, and since 10.04 have only supported armv7.
<GrueMaster> You might have better luck with debian arm.
<arcaico> Ok GrueMaster, I will give a researched
<GrueMaster> mahmoh: Have you been able to do preseeding with netinstall yet?
<mahmoh> not yet, should work fine though
<GrueMaster> Ok.  No worries, just curious.
 * GrueMaster was getting ready to reinstall on one of the pandas in the pool.
#ubuntu-arm 2011-07-22
<siji> hi all
<persia> Hey siji.  You7ve been looking for me when I haven't been around.
<siji> persia, hi
<siji> yes
<siji> i have finished the xbmc build on natty
<siji> but it's giving some runtime error
<siji> python: can't open file '/usr/local/share/xbmc/FEH.py': [Errno 2] No such file or directory
<persia> Is there some FEH.py file somewhere?
<siji> frm xbmc IRC , they were telling that something wrong with build
<siji> yes it's there
<persia> Also, for questions like that, it's better to just ask the question, and whoever is around will answer.
<persia> It's there, and in that location?
<siji> yes I asked .. but no respond :(
<siji> ya, but according to xmbc irc the build will never look for such file
<siji> for starting xbmc
<persia> Very strange.
<siji> so i guess smthing is wrong in my conf. parameter
<persia> It sometimes happens that things work differently, but usually that's intentional.  If upstream says the file should never be used, I'd recommend repeating the process of making it happen, documenting each step along the way, and submitting that as a bug upstream.
<siji> persia, sure will do
<persia> They might tell you something in Ubuntu is broken, but they'll probably tell you what is broken, and we can make sure that gets fixed.
<siji> persia, just want to confirm my build process is also proper
<persia> Alternately, they may find something broken in the configuration, or be surprised by some strange build process thing that only shows up if certain things are done.
<siji> ya am trying to get some help frm xbmc developers
<siji> regd.build process
<siji> I have generated natty image using rootstock
<siji> then frm the host PC chroot 'ed to that image and built xbmc there
<siji> and make install  prefix folder copied to my beagleboard natty
<siji> Hope this method will work
<persia> It might.  I would have just built it on the beagleboard directly.  Fussing with some other computer can only complicate things.
<siji> ok
<siji> btw, will it possible to increase the natty image size
<siji> in rootstock i have defined 1.2GB , now it's telling no space left
<persia> Yeah, but.
<siji> (anyway, i have started the rootstock with 8GB)
<persia> You'd need to create a new image file, format it with a new filesystem, and move the files.
<siji> persia, i think better to create new rootstock image right
<persia> Certainly easier :)
<siji> ok
<siji> another doubt is about vdpau
<siji> I have defined --disable vdapu , while building XBMC
<siji> since it was giving some error which is related to this
<siji> So this video decoder is necessary for omap ?
<siji> or it's need only for nvidia
<siji> cores/VideoRenderers/RenderManager.h: In member function âvoid CXBMCRenderManager::AddProcessor(CVDPAU*)â:
<siji> cores/VideoRenderers/RenderManager.h:114:20: error: âclass CLinuxRendererGLESâ has no member named âAddProcessorâ
<persia> No idea :)  I like to pretend all hardware is identical (although I'm not always successful)
<siji> ok
<siji> fine
<persia> That looks like a more general error, that probably needs investigation.
<siji> ok, it resolved by adding --disable-vdpau
<persia> Maybe some issue with templates generation in preprocessing.  Maybe some ifdef that isn't clean on ARM.  But *something*, because that's the class of error that should make xbmc not work at all.
<siji> persia, ok
<persia> Well, it was hidden with --disable-vdpau.  Hidden and solved are different (although hidden is fine for most folk)
<siji> ok :)
<siji> persia, something off topic
<siji> have you aware of exfat filesysem
<siji> Which is patented my MicroSoft
<siji> I read somewhere that samsung is paying 15$ per each phone to Microsoft , because of this filesystem
<brendand> as far as i know the only thing special about it is that it's 64-bit
<persia> I've never heard about it.
<siji> oh I missed some point, this exfat is used by android I think
<malfet> hi all
<malfet> can somebody help me understand logic behind arm assembly sequence
<janimo> malfet, which sequence in particular?
<malfet> janimo, "mov     r2, sp; bic     r4, r2, #8128;  bic     r4, r4, #63; "
<malfet> Why there are two bic instructions?
<malfet> (code snippet about is from objdumped kernel_init)
<janimo> malfet, the immediate values that can be put in bic (and other ARM intructions that accept such constants) are restricted
<janimo> so they can be expressed in a limited number of bits
<janimo> so if you want a value that is not expressible as a sum of power of twos you may need to use more than one instructions
<malfet> oh, so bic is encoded as #BIC_OP|#REGA|#REGB|#IMM|#IMM_SHIFT?
<janimo> malfet, do not know off the top of my head but since you are limited to 32 (or 16 for thumb) bits for an instruction you cannot fit a full 32 bit constant there as you need space for the opcode and other metadata
<janimo> malfet, the ARM docs described this in much detail
<janimo> so 8128 can be put there easily as it is exactly 2^13
<janimo> well not exactly actually
<malfet> janimo, got it. thanks a lot for explanaiton
<janimo> malfet, was a bit vague but this is the general idea :)
<malfet> forgot that all ARM instructions are conditional, so there is not enough space for 16-bit imm (like on ppc/mips)
<janimo> malfet, right, after refreshing my memory, 12 bit values, but only those obtainable by a 8 bit value plus an up to 4 bit rotate
<malfet> another newbie questions: r1-r3 doesn't have to be preserved across function calls?
<malfet> or is it true only for aapcs abi?
<janimo> malfet, are registers used for arguments, not preserved AFAIK. r0 is return value
<janimo> this is what I know from the ABIs I used and from the asm code I saw
<malfet> ok
<janimo> I am not even sure anything is preserved automatically across calls. One needs to store load explicitly if needed
<dmart> malfet, janimo: In Thumb-2 (i.e., on ARMv7) you can have most of the same immediate constants that you can have in ARM
<malfet> looks like ABI mandates r4-r11 to be preserved across the calls
<dmart> In Thumb-2, you can have constants of the form 000000xy 00xy00xy xy00xy00 and xyxyxyxy, as well as an 8-bit value shifted to any bit position.  However, Thumb-2 doesn't allow constants where the value is rotated across the end of the word (i.e,. 0xC000000E is allowed in ARM, but not in Thumb-2)
<malfet> interesting
<dmart> malfet: You can find docs describing the procedure call standard on infocenter.arm.com
<malfet> reading thru it now
<malfet> thanks
<dmart> malfet: Your understanding sounds correct though -- across a function call, r4-r11,sp must be preserved; r0-r3,r12,lr can be clobbered; r0-r3 are used for arguments, r0 for the return (r0-r1 for 64-bit values).  Extra arguments are passed on the stack if needed
<YuLin> Is there any existed directfb-ubuntu distro release?
<ScottK> persia: I was wondering if you had any suggestions about how to pursue fixing https://launchpadlibrarian.net/75437592/buildlog_ubuntu-oneiric-armel.vlc_1.1.11-1ubuntu1_FAILEDTOBUILD.txt.gz
<slangasek> rsalveti: hmm!  happy to follow, but I hadn't received any notice of the qemu-linaro release
<rsalveti> slangasek: at linaro-announce, posted yesterday :-)
<rsalveti> fresh news
<slangasek> ah... not on that list, Peter has notified me directly in the past
#ubuntu-arm 2011-07-23
<persia> ScottK: That's not a class of error I've seen before, unfortunately.
<ScottK> OK.  Thanks.
<rbelem> rsalveti, ping
<rsalveti> rbelem: pong
<rbelem> rsalveti, :-)
<rbelem> rsalveti, i need your help
<rbelem> rsalveti, i ve been trying to boot ubuntu in the pandaboard
<rsalveti> rbelem: sure, what's up?
<rbelem> rsalveti, but it always end up "ALERT!  /dev/mmcblk0p2 does not exist.  Dropping to a shell!"
<rbelem> iniramfs
<rsalveti> rbelem: what image are you using?
<rbelem> rsalveti, ubuntu 11.04 headless
<rsalveti> rbelem: is this happening at your first boot?
<rsalveti> first boot should do the disk resize
<rbelem> rsalveti, yup
<rsalveti> after that it doesn't point the disk as mmcblk0p2
<rsalveti> but with the uuid
<rsalveti> rbelem: could be your card is corrupted
<rbelem> rsalveti, i fscked it
<rsalveti> by the way you're writing the file, or even the sd card that's not that compatible with panda
<rbelem> rsalveti, i tried one kingmax and one kingstone
<rsalveti> rbelem: how are you writing the image file?
<rsalveti> rbelem: did you check the md5 from the image file?
<rbelem> rsalveti, i did not check
<rbelem> i will check it now
<rbelem> rsalveti, it matches
<rbelem> rsalveti, i tried the bash -c zcat methods
<rbelem> rsalveti, but it was gerating corrupted fs
<rsalveti> rbelem: try just with dd
<rbelem> rsalveti, then i dd
<rbelem> failed too
<rbelem> rsalveti, i manually created the filesystem and mounted the image partitions
<rbelem> rsalveti, but it did not boot
<rsalveti> rbelem: try grabbing the 11.06 linaro image
<rbelem> i'm downloading it right now
<rsalveti> rbelem: https://wiki.linaro.org/Cycles/1106/Release
<rbelem> rsalveti, the LEBs?
<rsalveti> rbelem: yes
<rbelem> nice :-)
<rsalveti> https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation
<rsalveti> http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/
<rbelem> rsalveti, two hours of download
<rsalveti> rbelem: ouch
<rsalveti> rbelem: you can grab the nano image
<rsalveti> hold on
<rsalveti> rbelem: http://releases.linaro.org/platform/linaro-n/nano/latest/
<rsalveti> with http://releases.linaro.org/platform/linaro-n/nano/latest/hwpack_linaro-panda_20110629-1_armel_supported.tar.gz
<rsalveti> it's a very basic image, but at least you can check if your board is working properly
<rbelem> rsalveti, thank you very much :-)
<rbelem> rsalveti, now it is better. it will take 10 min
<rbelem> :-)
<rsalveti> :-)
<rbelem> rsalveti, do i need to pass a binary image to linaro-media-create?
<rbelem> rsalveti, or i just need to pass the hwpack?
<rbelem> ah! i got
 * rbelem downloads nano-n-tar-20110628-1.tar.gz
<rbelem> rsalveti, chroot: failed to run command `linaro-hwpack-install': No such file or directory
<rbelem> rsalveti, i found the problem
<rbelem> rsalveti, scratchbox :-P
#ubuntu-arm 2011-07-24
<rbelem> rsalveti, ALERT!  /dev/disk/by-uuid/339475a9-7752-42b3-9c70-a202d2781062 does not exist.  Dropping to a shell!
<nicofs> I just added the ubuntu repos to my /etc/apt/sources.list - but all "apt-get update" returns is 404 - not found. Why could that be the case? The device in question is ARM - but basically that should be in the repos aswell... or not?
<rbelem> rsalveti, it worked
<rbelem> :-)
<Python> Hi
<rsalveti> rsalveti: awesome
<nicofs> What line do i have to ann to sources.list to get ubuntu arm sources? apparently *.archive.ubuntu.com doesn't include arm...
<nicofs> *add not ann
<rbelem> thnks rsalveti
<rsalveti> nicofs: you need to use ports
<rsalveti> like deb http://ports.ubuntu.com/ubuntu-ports natty main universe
<nicofs> rsalveti, thanks... 404 is gone - let's wait for the next errors to pop up...
#ubuntu-arm 2012-07-16
<ogra_> bug 1014139
<ubot2> Launchpad bug 1014139 in flash-kernel "flash-kernel fails to umount flash device after writing" [High,Fix released] https://launchpad.net/bugs/1014139
<janimo> ogra_, in nvtegra-graphics we probably should use arm-linux-gnueabihf suffixes for the alternative symlinks just to be in sync with the fact they're now armhf
<ogra_> feel free to port it :)
<ogra_> though i dont think the x86 version actually uses much of multiarch
<janimo> can be included in the next upload I guess
<ogra_> great, i have the final release of v15 here on disk
<janimo> nvidia devzone sitll down
<janimo> oh the one from july 6?
<janimo> can you put it somewhere if you are not packaginging it? :)
<ogra_> -rw-rw-r--  1 ogra ogra 6,8M Jul 10 10:19 ventana_nv-tegra_base_R15.1.0_armhf.tbz2
<ogra_> jul 10th, but yes
<janimo> ok
<janimo> just before their site was shut down
<janimo> although I see the relnotes mentioning they still have arterfacts with gtk, on resume, etc
<ogra_> yup :)
<lilstevie> ogra_, have you checked if the ventana and cardhu versions differ at all
<lilstevie> yeah, they are ok though
<ogra_> lilstevie, i havent checked anything yet, banging my head against an image problem currently
<lilstevie> although I have noticed if you aren't using the -r15-rc tag you will have problems
<ogra_> i just grabbed the tarball in case the site might go down ;)
<lilstevie> ogra_, ah
<janimo> ogra_, is the image problem due to needing to pass console= or due to initramfs size limitation?
<lilstevie> the downloads are still available via their direct links fwiw
<ogra_> janimo, well, console= is in now, so that shouldnt cause issues, currently it does with "no init found" i assume thats the size issue
<janimo> lilstevie, I googled in vain for such links? Do you have them ? :)
<ogra_> http://people.canonical.com/~ogra/tegra/ventana_nv-tegra_base_R15.1.0_armhf.tbz2
<ogra_> still uploading
<janimo> lilstevie, r15-rc you mean tag in nvidia kernel git repo?
<lilstevie> yes
<janimo> lilstevie, what do they do in the kernel that is so intertwined with the graphics drivers?
<lilstevie> Couldn't open /sys/bus/nvhost/devices/host1x/syncpt/22/max
<ogra_> janimo, done, feel free to pull
<janimo> ogra_, thanks
<lilstevie> janimo,  the fact that the userspace driver has to rely on kernel interface
<janimo> lilstevie, but what specifically?
<lilstevie> a whole heap of stuff
<janimo> what kernel APIs/ABIs they change?
<janimo> anything standard or nvidia specific drivers only
<lilstevie> nvidia specific
<janimo> so dev/nv* stuff?
<janimo> ok
<lilstevie> sys/bus/nv* stuff
<lilstevie> the error with es2gears is Couldn't open /sys/bus/nvhost/devices/host1x/syncpt/22/max
<janimo> I am sure for the ac100 we used kernels which were not the exact versions nvidia recommended/shipped with the L4T but it still worked more or less
<lilstevie> and checking the path syncpt doesn't exist
<janimo> lilstevie, so right now using 15 final and the git tag you mentioned should be all ok?
<lilstevie> should be
<lilstevie> need to sync to that tag myself
 * ogra_ didnt have any issues with our kernel and the v15beta
<ogra_> did they really change so much between beta and final ?
<lilstevie> they added a whole heap of stuff
<lilstevie> for use of HDMI fcbon
<lilstevie> fbcon*
<lilstevie> ogra_, I didn't think there was an issue until I tried es2gears
<ogra_> well, es2gears worked on beta with our 3.1 kernel
<lilstevie> yeah es2gears worked with beta here too
<ogra_> as well as unity and compiz
<lilstevie> it is with the release that didn't
<lilstevie> ok I have a unity issue
<ogra_> transparency ?
<lilstevie> menubar is gone
<ogra_> thats known and i guess a driver issue
<lilstevie> and the top bar
<ogra_> its there, just transparent
<lilstevie> dash home and hud
<lilstevie> yeah
<ogra_> you can click on items, open menus etc
<lilstevie> sorry, yeah they are there, but transparent
<ogra_> yeah, very likely a driver issue
<ogra_> since it works on PVR
<lilstevie> but not being able to see dash home is a bit of an issue :p
<ogra_> pfft ... it trains your fantasy
<lilstevie> lol
<lilstevie> in any case, makes accelerated unity unusable
<ogra_> right, currently: use a panda for that :)
<lilstevie> yes, well I don't have one of those
<lilstevie> just 3 tegra powered devices :p
<lilstevie> I figured it was a driver issue though, cause the same happens on my trimslice
<ogra_> so pray that nvidia fixes their driver some day :)
<lilstevie> lol
<ogra_> i'm pretty sure there is a function missing in their GLES implementation
<lilstevie> so someone needs to log a bug
<ogra_> i heard unity works on mali too ...
<ogra_> so PVR and mali should be fine ...
<ogra_> not sure about the amd chips that freescale uses on their boards ...
<ogra_> janimo, did you ever test 3D stuff on the mx5 ?
<janimo> ogra_, not besided the factory SD card, which has nicely working 3D
<ogra_> ah
<janimo> I think I had the NDA'd proprietary 3d libs too
<janimo> but I can't recall if I could make them work
<ogra_> would be intresting to know if unity works there ... but i guess thats to much effort
<janimo> or maybe I did not even have them
<janimo> of little use for users if the libs are not freely available
<lilstevie> yeah, so we need to figure out what is missing from the nvidia ones, then pester them for 2 years until they fix it
<ogra_> in which case we will have switched to wayland and have to start over bugging them about the same issue in a new driver
<ogra_> :)
<janimo> ogra_, lilstevie above disussion makes it sound we do not want to upgrade to l4t 15 final :)
 * ogra_ prefers that we do 
<lilstevie> janimo, why?
<ogra_> at least to get rid of the CSS bugs etc ... telling people to switch to unitty-2d isnt as bad as having broken screens
<janimo> lilstevie, regressions due to our kernel not being in sycn with what l4t expects
<lilstevie> janimo, there is no real regressions that you notice, so far I have only noticed an issue with es2gears and es2tri
<lilstevie> and the solution there is to not be lazy and just update the kernel
<janimo> lilstevie, well yes, we should update them more or less in sync
<janimo> maybe marvin24 rebases on the new kernel soon :)
<lilstevie> what does marvin24 have to do with it, he isn't even involved in the kernel that I use on the tfx01
<ogra_> but we use that kernel :)
<janimo> lilstevie, we use his kernel for ac100 in ubuntu
<janimo> lilstevie, but feel free to maintain a more proper tegra kernel in Ubuntu :)
<lilstevie> heh
<lilstevie> janimo, infinity and I have discussed this a few times
<janimo> noone would mind if it booted both ac100 and tf
<janimo> I know.
<lilstevie> it is a nightmare due to a bunch of OEMs using the same mtype
<janimo> lilstevie, well in a year we'll have DT tegra trees in Ubuntu, until then we try to use hacks and external kernels :)
<lilstevie> janimo, but yet we won't have DT bootloaders for all devices
<ogra_> what ? a year ?!?
<lilstevie> the 3.1 kernel supports DT fwiw
<lilstevie> the nv-tegra one
<janimo> The tegra-l4t-r15-rc tag seems to have the last commit in May. Not extremely recent
<janimo> lilstevie, well full support as in actually working and replacing the current board specific code
<lilstevie> again, still won't have it for every device
<janimo> ogra_, maybe in a year mainline kernel will have all tegra stuff merged and working
<ogra_> janimo, ah
<janimo> lilstevie, no need for every device
<marvin24> janimo: the kernel in my branch is based on the latest nv code already, will test the new driver later on
<lilstevie> I mean it was only today that it even became safe to test alternate bootloaders on the tf201
<janimo> ans popular ones will be easier to add than now
<janimo> marvin24, indeed I hope it is not too complicated. Did you base it on tegra-l4t-r15-beta ?
<marvin24> lilstevie: did you got u-boot and 3.1 kernel running?
<janimo> if you could git push --tags it may be easier to guess :)
<marvin24> janimo: no, rel-15r7
<lilstevie> marvin24, u-boot no
<lilstevie> Linux steven-laptop 3.1.10-1000-tegra #0 SMP PREEMPT Thu Jul 12 01:26:55 EST 2012 armv7l armv7l armv7l GNU/Linux
<lilstevie> kernel yes
<lilstevie> :p
<lilstevie> but we aren't using the r15-rc tag yet
<lilstevie> also rel-15r7 and r15-rc differ
<janimo> marvin24, ah indeed, the branch. Confusing branch and tag names all the time
<marvin24> well, I fact I used the tegra-15r7.1-android-4.0 tag
<marvin24> maybe I should also start to tag ...
<lilstevie> I haven't seen the r15 hdmi code in 15r7
<ogra_> ok, todays image still dies with "no init found" ... sadly i cant get any more info out of that kernel
<ogra_> even dropping quiet and spalsh doesnt print any more stuff
 * ogra_ guesses thats still the console= issue
<janimo> lilstevie, you're on transformer prime?
<janimo> ogra_, is the initrd from the current bootimg causing the issue? I'll try debugging it with locally built zImages
<janimo> just need a good (broken) initrd
<lilstevie> janimo, of course
<ogra_> janimo, http://cdimage.ubuntu.com/daily-preinstalled/20120716/quantal-preinstalled-desktop-armhf+ac100.bootimg
<ogra_> abootimg -x  gets you the initrd from it
<ogra_> btw, is there any reason why we use tty1 not tty0 ?
<lilstevie> ogra_, working around the old console bug
<ogra_> lilstevie, right, by why tty1 (which forces you into a black screen) instead of tty0 ?
<janimo> ogra_, ok, flashed and got the bug. I'll have a look and see if I find the reason
<ogra_> janimo, cool, thanks, i will aslo try to experiment with different and smaller initrds
 * ogra_ switches the default to tty0
<lilstevie> ogra_, the 2.6.39 kernel needed it afaik
<lilstevie> to show the console
<lilstevie> it is an old bug anyway
<ogra_> we never used it
<lilstevie> no longer present
<ogra_> its not
<lilstevie> we did
<ogra_> its a brandnew bug with 3.1
<lilstevie> oh hm
<ogra_> (for ac100 that is)
<lilstevie> wait, the plymouth bug
<ogra_> no
<lilstevie> or one where the console doesn't show
<ogra_> plymouth is a different issue
<ogra_> right, console doesnt show regardless of plymouth
<ogra_> unless you set console=tty*
<lilstevie> ok, console not showing is an old bug that only affected .39 here
<ogra_> and we defaulted to tty1 ...
<lilstevie> tty0 works just fine here
<ogra_> right
<ogra_> and you actually get kernel messages if you use tty0
<ogra_> ;)
<lilstevie> yes
<ogra_> (instead of tty1)
<lilstevie> yes
<ogra_> all workarounds and howtos for ac100 i have seen yet talk about tty1 though ...
<lilstevie> hm
<lilstevie> volume is killing me :/
<lilstevie> I have no volume control on the prime
<lilstevie> either sound is on, or muted
<scientes> who runs the armel buildds?
<scientes> My package needs a newer kernel for 8 byte atomics on armel, which apparently have been recently added to gcc, which my configure script picked up
<lilstevie> people use armel builds?
<scientes> doesn't infinity run those?
<ogra_> the canonical IS team runs all  buildds
<ogra_> (no matter what arch)
<scientes> otherwise i can switch it back to the last version where it actually test ran the binary
<scientes> but i moved to just link testing so that the package can be cross-built
<janimo> ogra_, progress
<janimo> repackaged the same initramfs using lzma and it boldly boots into the no tarball found initramfs
<janimo> lz packed size is : 2049358
<janimo> quite under the 2M limit
<janimo> so we should default to lzma initramfs's like the rest of ubuntu does - or to xc if that is used (I forgot which was the latest)
<janimo> although weird my x86 ones in /boot seem to be gzip compressed
<janimo> either way, we should try ac100 builds with lzma
<ogra_> will check how hard it is to switch it (iirc i already ship a specific initramfs-tools.conf)
<ogra_> ah, sad, thats only the in-initrd config
<ogra_> fix uploaded :)
<ogra_> lets see if that works even if not done manually :)
<scientes> what version of gcc do i need for those 8 byte atomics on armv5? (i'm just trying to figure out the kernel version)
<scientes> cause debian unstable gcc doesn't have it
<scientes> *wheezy
<ogra_> better ask in #linaro as they maintain the toolchain
<scientes> anyways, my package needs a newer kernel on the buildds
<scientes> to match the toolchain, for armel, not armv7
<ogra_> how new ?
<scientes> for the test suite
<ogra_> well, armel isnt actually supported by ubuntu atm
<scientes> ogra_, i was trying to figure out, but my gcc doesn't have the feature that the ubuntu toolchain does
<scientes> (8 byte atomic operations for armel)
<ogra_> we left it in place since there is a 1% chance that we will keep it in 12.10 ... but even that 1% shrinks with every day of the release cycle
<scientes> well do you know what kernels debian uses on buildds?
<ogra_> no idea
<scientes> cause as soon as they upgrade gcc i will end up with same problem there
<ogra_> i dont even know what HW they have
<scientes> they are using real armv5 hardware for the armel port
<ogra_> unstable should have the same gcc we use in ubuntu though
<scientes> checking for 8 byte atomic operations... yes
<ogra_> right, we dont have or support any armv5 hardware at all anymore
<scientes> I get no, using wheezy toolchain
<ogra_> wheezy != unstable :)
<scientes> well i didn't downgrade, it was unstable as of 2 weeks ago
<ogra_> anyway, targeting armel with ubuntu is probably wasted effort
<scientes> so after the debian import freee
<ogra_> did debian rename sid ?
<ogra_> to me sid == unstable ...
<scientes> ogra_, i'm pretty sure ubuntu uses their own toolchain
<scientes> from linaro
<scientes> instead of FSF/sourceware
<ogra_> scientes, well, i'm pretty sure our toolchain gets uploaded to debian and then synced from there
<scientes> at least for arm
<ogra_> since several releases now
<scientes> ahh that sounds sensible too
<scientes> cuase the docs say that 64-bit atomics arn't on arm
<scientes> but apparently they are
<ogra_> (given the maintainer is the same in linaro, ubuntu and debian)
<scientes> and i googled the kernel patches
<scientes> its good for performance of the package
<scientes> ohhh!, you guys switched to gcc-4.7
<ogra_> yes
<scientes> debian is still on gcc4.6 except for x86 and amd64
<ogra_> well, unstable should be on 4.7 too
<ogra_> i'm pretty sure doko uploads to both distros at the same time
<scientes> probably wont change until after wheezy is released
<ogra_> but anyway, armel amd especially pre- armv7 is dead beef on ubuntu
<ogra_> s/amd/and/
<scientes> ok, so i wont care the test dont run, ergo it doesn't build
<scientes> and check out debian setup
<ogra_> its very  likely that armel will be removed from the archive by feature freeze
<ogra_> unless someone steps up and pays for it
<scientes> thats ok for me, debian works fine
<ogra_> janimo, do you know from the top of your head if we have xz initrd handling enabled in the ac100 kernel ?
<ogra_> seems the consensus is to not use lzma
<scientes> ogra_, you mean lmza2 (xz)
<scientes> ogra_, its actually broken in linux 3.5
<scientes> xz is
<ogra_> we only have 3.1 for ac100
<scientes> due to merge bug
<scientes> ahh lzma works then
<scientes> but its slow
<scientes> gzip is the fastest
<ogra_> yes, but thats not the preferred method
<ogra_> i was asked to switch to xz
<scientes> lzma also have VERY high memory to compress requirements
<ogra_> i just dont know if the current ac100 kernel supports it
<scientes> ogra_, well fix the 3.5 bug then
<ogra_> as i said, we only use 3.1
<scientes> xz was merged in 3.5, but its broken
<scientes> i reported it, but nobody cared to fix it
<ogra_> janimo, i still get stack-protector kernel errors here :(
<ogra_> no matter if i use xz or lzma
<ogra_> grmbl
<ogra_> still corrupted kernel stak :(
<ogra_> *stack
 * ogra_ hates kernels
<ogra_> why cant we live without them !
<cooloney> ogra_: oh, come on
<ogra_> cooloney, they always cause problems !
<ynezz> use heap!
<janimo> ogra_, sorry, was away. I used lz and it worked with the stock kernel in the bootimg
<janimo> so not xc
<ogra_> janimo, right, i tried both
<ogra_> neither works
<janimo> weird
<janimo> I just repacked the initrd there
<janimo> what sized did you get?
<ogra_> did you change anything wrt config of the bootimg ?
<ogra_> -rw-rw-r-- 1 ogra ogra 2052736 Jul 16 18:04 initrd.img
<ogra_> thats my lzma packed one
<janimo> close enough, mine was almost the same
<ogra_> oh, wait, did you cpio it or just unzip and then lzma ?
 * ogra_ actually unpacked his
<janimo> cpio too I think
<ogra_> k
<janimo> I have two unpack repack scripts
<janimo> $CAT $initrd | ( cd $ramdisk; cpio -i )
<ogra_> well, in any case i always get "stack-protector: Kernel stack is corrupted in: c06a594c"
<janimo> ( cd $ramdisk; find | sort | cpio --quiet -o -H newc ) | lzma > $initrd
<janimo> so unpack and pack
<ogra_> yeah, pretty much the same i did here
<janimo> I only saw uncompress error with the original img, which then obviously turned into init not found
<ogra_> just mnot piped together ... but that shouldnt matter
<janimo> I did not pipe them either
<janimo> I mean not the unpack to the pack
<ogra_> nah, indeed
<ogra_> i mean i manually unzipped, manuall ran cpio .. etc
<ogra_> janimo, any changes to the bootimg.cfg ?
<ogra_> or do you ise the default one from the bootimg file ?
<janimo> cmdline = mem=512M@0 tegrapart=recovery:300:a00:800,boot:d00:1000:800,mbr:1d00:200:800 console=tty1 root=/dev/mmcblk0p7
<janimo> just removed the quiet splash loglevel stuff
<janimo> to get more info
<ogra_> right, looks like the default one
<janimo> if that makes the difference maybe calling splash causes the issue
<ogra_> i dont have quiet and splash here
<janimo> so similar
<ogra_> right
<janimo> maybe your unit has a hw issue?
<ogra_> well, precise works fine
<ogra_> so i doubt that
<janimo> http://startx.ro/~jani/o.img
<janimo> this is what works for me
 * ogra_ pulls and tests
<janimo> but it cannot find the tarball on the usb stick
<ogra_> bah ! why does that boot
<ogra_> janimo, yeah. looks like a live-build issue, the installer.md5 file has a wrong name
<ogra_> janimo, oh !
<ogra_> the kernel misses cp437, it cant mount
<ogra_> (needed for vfat)
<janimo> indeed, that's what I saw
<janimo> I wonder if I dropped that last time
<ogra_> kernel issue then :)
<janimo> so going to add that back
<janimo> :)
<ogra_> thx
<janimo> so the initrd is now packed with lz? nice
<ogra_> it still bothers me that i dont know why my initrd doesnt work
<ogra_> yeah, we're the only ones being that inoovative :)
<janimo> put the current bootimg that does not boot somewhere, I'll try that too
<ogra_> seems lz was several times discussed ... but using it breaks rsyncability
<janimo> ogra_, lz for initrd or the whole squashfs?
<janimo> I know squashfs/lz was discussed a lot. Not even sure what is used now for squashfs
<ogra_> well, i asked about initrd in -devel
<ogra_> janimo, http://people.canonical.com/~ogra/tegra/quantal-preinstalled-desktop-armhf+ac100.bootimg
<janimo> ogra_, just read devel backlog
<janimo> it was not clear from Colin's answer that he referred to initramfs and not the whole live image
<janimo> anyway. for our case as you said lack of rsyncability is not an issue
<ogra_> yes, bootimg isnt even offered via zsync/rsync i think
<ogra_> and its small enough that even if it would be, pulling it as a whole isnt that bad
<ogra_> its only 8M after all
<scientes> ok it was added in 2.6.30---its just that its only supported on armv6k+
<scientes> i have no idea how it manages to fail on your modern hardware...
<janimo> ogra_, nothing changed in the configs AFAICT 437 is there in the configs
 * ogra_ scratches head
<janimo> ogra_, although there's no nls/*ko in lib/modules in the initramfs
<janimo> kernel/fs/nls is nonexistent
<janimo> I wonder if earlier initrds had that
<ogra_> hard to tell, i havent had one that booted this release cycle
<ogra_> janimo, not precise
<ogra_> ogra@anubis:~/Desktop/tegra$ ls lib/modules/3.0.27-1-ac100/kernel/
<ogra_> drivers  fs
<ogra_> no nls ... but fat avd vfat are in the fs subdir
<ogra_> and they worked
<ogra_> probably nls was compiled in and is now modular ?
<janimo> ogra_, you got it, that
<janimo> is the issue
<ogra_> :)
<janimo> I'll revert it
<ogra_> thx
<ogra_> btw, the installer can also use ext2
<janimo> ah, so not showstoper but mportant still
<ogra_> right
<ogra_> annoying if you used vfat and have to re-do your SD though
<marvin24> may I ask if tfx01 suffers from the same console problem?
<ogra_> lilstevie, ^^^
<scientes> IMHO you guys should be using your own 3.2 kernels
<ogra_> ou own ?
<ogra_> *our
<scientes> precise is 3.2
<ogra_> not for ac100
<ogra_> we only had a 3.0 tree for qunatal
<ogra_> err
<ogra_> precise indeed
<scientes> is it tegra 2 or something, and you are held back by old shit?
<scientes> *binary shit
<ogra_> it is tegra2 and we are depending on nvidia and chromeos commits
<gildean> all tegra2 devices are held back afaik, i've not seen a tegra2 device with a modern kernel
<ogra_> yep
<gildean> and i have three different tegra2 devices atm
<gildean> fortunately paid for none
 * ogra_ too
<ogra_> but i paid for some :)
<gildean> i could've bought a galaxy tab 8.9 if i didn't get one from work
<scientes> eek, its 3.4 kernel feature
<scientes> guess I can't ask for that
<scientes> even though quantal will have it
<janimo> marvin24, it keeps being unclear to me whether we need CONFIG_PCI in the ac100 kernel
<janimo> I think it used to be both on and off (PCIE too) with no noticable effect as far as I remember
<janimo> I am looking at the config changes introduced with the 3.1 kernel, as one slipped through and lead to unmountable fat partitions
#ubuntu-arm 2012-07-17
<lilstevie> marvin24, if you mean the blank console issue where you get no kmesg with fbcon enabled, no, it only affected us for 2.6.39, at least on the tf201, there isn't a good solid properly ported tf101 3.1 kernel yet to comment on, so it could possibly be a tegra2 bug
<robclark> btw, anyone tried kde / kwin_gles?  It seems like /usr/lib/kde4/kcm_kwincompositing.so is linked against libGL.so instead of gles (this is w/ kde-window-manager-gles)
<infinity> robclark: Patches welcome. ;)
<infinity> robclark: The whole QT/GLES thing is a royal pain to mangle.
<robclark> infinity, ok.. I was just chasing up a bug reported on pandaboard list from someone who had somehow enabled desktop fx... so was wondering if I had missed installing something..
<infinity> robclark: To be fair, I have no idea what does and doesn't work, I try out KDE so very infrequently.
<infinity> robclark: All I know is that the GL/GLES abuse between ARM and $everything_else makes all things QT and KDE a porting nightmare. ;)
<janimo> ogra_, I tried the ac100 installer with a local kernel that has the NLS pieces built in. It goes on but it does not write the config boot image and boots into the initial one. There are errors saying init: abootimg not found
<infinity> janimo: Which sounds a whole lot like abootimg isn't installed. :P
<scientes> why arn't you guys running precise kernels on your buildds?
<janimo> infinity, right, but I am not sure anything should have changed in the initrd generation, hence calling ogra :)
<infinity> scientes: Because they're not all precise.  Did a build blow up due to kernel version?  Point me at it, and I can fix it.
<infinity> scientes: The plan is to upgrade them all to precise/armhf over the next week or two, but it's a reinstall (since they were previously natty/armel), so a bit irksome.
<scientes> infinity, well actually i did my research, and my package would need 3.4 to build with its current settings, i downgraded a try-execute test to a link-test, and never realized that gcc-4.7 has support for 8-byte atomics on arm
<janimo> infinity, ABI bump needed for kernel modules/built-in changes or just strictly for actual changes in the signatures, data structs?
<infinity> scientes: 3.4? Eh?
<scientes> so the setting is incorrect, and next upload will hard code turning it off on armel
<infinity> scientes: The atomic helpers in the kernel are in 3.1
<janimo> I see skipabicheck and skipmodulecheck as different toggles, so I think that may be the case
<scientes> <armv6k added kernel 64-bit atomic support in 3.4
<infinity> scientes: Trust me.  Which package is this?
<scientes> oh really
<infinity> scientes: No, really.  Trust me. :P
<scientes> i just used git describe
<infinity> scientes: It'll build on sigbin.
<scientes> ok kyotocabinet
<infinity> Yeahp, that will build fine on sigbin.  I'll toss it there now.
<infinity> janimo: Hrm?  abicheck is all about exported interfaces.  If a module is built-in, it wrong trigger it.
<infinity> janimo: Of course, modulecheck will blow up if you're moving modules around from built-in to not (was that the question?), and yes, that should be an ABI bump.
<infinity> janimo: Enabling something that wasn't previously on at all, however, would not be an ABI bump.
<infinity> janimo: (unless it changes something else)
<janimo> infinity, ok. Just did not know whether ABI change is a superset of drivers moving drom built-in to modules or vice-versa change
<janimo> this is actually from modules to built-in
<janimo> NLS modules for the installer to be happy
<infinity> janimo: Strictly speaking, "ABI" was originally meant to just represent the module ABI, so ignored the modules themselves, but we now use it as a superset to also deliver guarantees of availability.
<infinity> So, if a module disappears (or moves between image and modular), that's a break.
<infinity> If one's added, that's perfectly fine.
<infinity> And I think I'm being repetitive now, so I'll shut up. ;)
<infinity> janimo: If in doubt, rev ABI.  It doesn't really hurt anything to be wrong in that direction.
<janimo> infinity, the only thing it hurts is new binaries and meta needed
<marvin24> janimo: pci-e is not used on ac100, I think I activated it sometime to shut down something (clock or pinmux), but I haven't measured power consumption yet
<marvin24> lilstevie: I mean kernel oops with plymouth (not no splash)
<roric> Hi all
<roric> I just tried to install 12.04 on a pandaboard, did a dist-upgrade
<roric> then tried to install the pvr driver via jockey
<roric> it fails... it did a while back when I tried too
<roric> any known workaround?
<ogra_> janimo, ah, yeah, thats just a missing chroot call, abootimg isnt in the initrd, i changed the bootconfig handling to match with flash-kernel 3.0 but forgot that i need to call abootimg chrooted from the target partition
<ogra_> i'm just preparing ext2 media here to do a test install
<ogra_> janimo, fix uploaded
 * ogra_ has oem-config :)
<pershoot> hi guys.  have you all come across this: Couldn't open /sys/bus/nvhost/devices/host1x/syncpt/22/max  ?  is there a set of patch(es) which adds this interface in?
<ogra_> grmbl
<ogra_> flash-kernel always exits "1" on the ac100, no wonder it doesnt work
<lilstevie> marvin24: the plymouth oops that locks up the whole system affects us too
<ogra_> yay, fixed
<ogra_> janimo, the next ac100 image shold be fully installable now (from ext2/3/4 media though)
<ogra_> silly bug in flash-kernel
<janimo> ogra_, great
<marvin24> lilstevie: are you able to dump the oops?
<marvin24> if not, does it look like this one http://paste.ubuntu.com/1095134/ ?
<ogra_> marvin24, bug 1018907
<ubot2> Launchpad bug 1018907 in plymouth "plymouth in quantal on arm does only boot with black screen" [High,Confirmed] https://launchpad.net/bugs/1018907
<ogra_> try the rm /lib/plymouth/renderers/drm.so workaround
<marvin24> ogra_: that's different I think
<ogra_> well, it makes plymouth by default talk to the kernel sdrm interface
<ogra_> *kernels drm
<marvin24> you mean this could cause an oops?
<ogra_> well, it would be a kernel bug, but yeah
<marvin24> I'll test it later on but i doubt that's the reason
<ogra_> i.e. on omap4 we have a drm device thats not connected to anything, there the plyouth output just gets /dev/null'ed
<ogra_> who knows whats there on nvidia ... very likely no drm device :)
<marvin24> tegra2 has no drm compiled into the kernel I think
<janimo> ogra_, is that issue fixed in ac100 by blacklisting something?
<lilstevie> marvin24, it does not look like that it just blacks out
<ogra_> janimo, nope
<ogra_> lilstevie, you should too try the workarouond from the bug above
<lilstevie> ogra_, ok I will get to it eventually
<ogra_> hmm, having the desktop defaulting to suspend on lid close but having the kernel break on suspend isnt really a great combo
 * ogra_ tries the nvidia driver from the archive with todays image
<lilstevie> haha
<lilstevie> I wish my lid close sensor was working correctly
<ogra_> BAH !
<ogra_> "module ABI major version (11) doesn't match the server's version"
<ogra_> GRMBL
<ogra_> there are days where i hate progress
 * LetoThe2nd hands ogra_ some i286 box.
<lilstevie> heh
<ogra_> *g*
<ogra_> k, fixed
<janimo> infinity, when adding a new package to a released series, what source does one file the SRU bug against?
<janimo> trying to get in new packages into 12.04
 * ogra_ would just file against the ubuntu product
<ogra_> after all the ubuntu-sru team works by subscription. so the package name shouldnt matter a lot
<janimo> ogra_, ok thanks
<janimo> sigh, forgot to touch modules.ignore (or was it ignore.modules) now ac100 kernel FTBFS :(
<janimo> I . HATE. PACKAGING
<janimo> double hate kernel packaging
<scientes> janimo, it wouldn't be such a pain if it didn't take so long to build
<janimo> I actually mind the time it takes of my life not of the build machines :)
<janimo> that is why I am sloppier about it than I would if we had some big timesharing server where we'd get limited cycles
<scientes> but if feedback of mistakes was faster you would learn better
<janimo> a conceptually simple change described in English as 'make NLS codepage 437 built in instead of module' which could be even terser in a special purpose language is a long series of error prone steps
<janimo> scientes, it is not about learning. It is stuff I more or less know but practice not frequently enough to have it on autopilot :)
<janimo> scientes, and it does not take that much when cross-building btw. On my fr from top of the line machine it is at most 20 min
<janimo> s/fr/far/
<scientes> janimo, except that when compiling on buildds you ARNT cross-compiling
<janimo> not long enough to be prohibitive, but long enough for my attention-span to go out the window a few times in that interval
<scientes> wow, i though a gcc compile was going to take forever, but not on a octo-core xeon ;)
<janimo> scientes, most bugs I can catch cross-building I just did not cross-build the 3rd time today
<janimo> forgot that crappy modules thing
<infinity> janimo: Err, a new source that isn't in quantal?
<jhobbs>  /wg 10
<janimo> infinity, good point, completely forgot that requirement, as this was OEM/HWE driver for 12.04.1 images
<janimo> I could upload to quantal now, with only a changelog bump right?
<infinity> janimo: You could do, yes.  We'd definitely prefer to see the source NEWed to quantal first, then backported to precise.
<janimo> infinity, shall I add a new changelog entry making it ubuntu2 - quantal and upload or something different? Not sure what a backport to precise should look changelog wise
<infinity> janimo: Would make more sense for ubuntu1 to go to quantal, and ubuntu0.12.04 (or similar) to precise.
<janimo> ah. ok. Please discard the 3 cedarview packages in NEW then
<infinity> Done.
<janimo> infinity, actually these depend on kernel patches too which intel only provided for 3.2.0. tseliot reminded me, I completely forgot about before
<infinity> janimo: Oh, you mean it literally can't be in quantal?  Fun.
<janimo> infinity, yes, but I overlooked that.
<janimo> maybe with a forward ported kernel patch but not at the moment
<infinity> janimo: I'd still upload to precise as if it were a backport (so, with a "backporty" version number), but yeah, guess we'll have to NEW it into precise at some point.
<janimo> is there any way of undoing the purge or do we need a new upload :D ? These need upgrade path from existing PPA version numbers so 12.04 may not work. Could you join #hwe ?
<janimo> otherwise I keep proxying between you and the other cedarview packagers and I may add noise :)
<janimo> infinity, so since I got confirmation that these won't work in quantal could you remove the vaapi upload to quantal of 5 min ago? thanks :)
<infinity> janimo: Rejected from quantal.
<janimo> marvin24, do nvidia take patches to their 3.1 tree? looks like quite a few of your paz00 patches could live there, the mach is in their tree already
<janimo> I just out of curiosity rebased our current ac100 tree on nvidia's l4t/15. seems there are about 120 patches over it in your tree if I count correctly, and about 60 more Ubuntu packaging commits
<marvin24> janimo: sure, I already forward some to them
<marvin24> what patches do you refer to?
<marvin24> ah, you mean to add full paz00 support to it?
<marvin24> not a good idea ...
<marvin24> the tree is only short living and who wants to take care of it?
<marvin24> on the other hand, bugfixes are welcome I guess
<marvin24> I already have enough stress to keep mainline up to date
<janimo> marvin24, well yes full paz00 that you carry now which does not affect other machs and some of it is already in nvidia's tree. But you know better :)
<marvin24> janimo: yes, not worth the effort IMHO
<marvin24> btw, removing the plymouth drm.o think didn't fixed the console problem
<cvanvliet_> the armhf SGX Ti binaries are available now?
<cvanvliet_> for omap3
<scientes> cvanvliet_, only the kernel is differn't between devices
<cvanvliet_> scientes, the omap3 Ti SGX armhf binaries have not been available, and I just saw someone using them, and I was just following this up
#ubuntu-arm 2012-07-18
<infinity> cvanvliet_: Using them from where?
<cvanvliet> infinity, http://elinux.org/BeagleBoardUbuntu#SGX_armel.2Farmhf_v3.4.x.2B
<LetoThe2nd> hm. tried the omap4 netboot installer, but board does not boot afterwards. 12.10's boot.img-serial.gz should be right?
<LetoThe2nd> or rather boot.img-fat-serial?
<infinity> LetoThe2nd: boot.img-serial.gz should be fine if you zcat it to a card.  If the installer ran all the way through, the image was fine.
<infinity> LetoThe2nd: But it's entire possible that it doesn't produce a bootable system in quantal.
<infinity> ogra_: Is flash-kernel-installer not doing nice things in quantal?  I've heard a few reports of netboot not producing bootable systems.
<LetoThe2nd> infinity: it ran all the way. ah, i see. will give it one more try with 12.04 for now
<infinity> LetoThe2nd: 12.04 should be just fine.  We use it all the time.
<LetoThe2nd> infinity: yeah, i just hoped i could already give 12.10 some testing
<LetoThe2nd> ah, and one more thing - do the arm port repos also provide rt-enabled kernels like for x86, or is there opportunity for playing?
<cvanvliet> infinity, I have asked in #beagle as well, I will let you know if I get any follow up, (afk)
<LetoThe2nd> hm, netinstall with precise also did not result in a bootable sd card. :(
<LetoThe2nd> ok, now i am pretty convinced that there is something fishy with the netboot installer taken from http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/boot.img-serial.gz
<LetoThe2nd> tried now twice with different sd cards, two times system is not booting anymore after successfully completing the installer.
<ogra_> file a bug, attach as many logs as you cnan find :)
<LetoThe2nd> image was written to block device using zcat image > device... everything correct so farÃ
<ogra_> right, but that image is a single partition image, flash-kernel doesnt know how to write to a device instead of to a partition
<LetoThe2nd> ogra_: hence?
<ogra_> well, at least for omap4 it expects to have mmcblk0p1
<ogra_> you could check if it still boots when you partition your SD first and then dd to the first partition
<LetoThe2nd> ogra_: can do that.
<LetoThe2nd> ogra_: something like creating a 60M fat16 partition on the blockdevice and then zcatting to that?
<ogra_> right
<LetoThe2nd> will do. report back in some minutes
<ogra_> thx
<LetoThe2nd> using the automagic partitioning afterwards is ok?
<ogra_> yes
<ogra_> it shouldnt care about the SD
<ogra_> only flash-kernel will in the end
<LetoThe2nd> ogra_: does not even boot.
<ogra_> ah, sad
<LetoThe2nd> indeed.
<ogra_> i'll look into it
<LetoThe2nd> thx
<ogra_> thanks for telling me
<LetoThe2nd> np.
<LetoThe2nd> shall i walk though the process once more using the block directly for zcatting, so i can inspect the card afterwards?
<ogra_> that would be helpful, yes
<LetoThe2nd> np, will be ready after lunch i guess.
<LetoThe2nd> ogra_: back with the sd card :)
<ogra_> so what does it show ?
<LetoThe2nd> ogra_: after the finished install process, the favorite symptoms of any pandaboard user: power on -> status led 2 solid on.
<ogra_> hwo does the SD look like ?
<ogra_> *how even
<LetoThe2nd> http://paste.ubuntu.com/1098130/
<LetoThe2nd> besides that, black and on the front side is printed "micro sd card 4gb class 10", on the back side it has some copper coloured contacts.
<LetoThe2nd> *SCNR*
<ogra_> oh, wait, you installed *to* the SD ?
<ogra_> janimo, ac100 images work fine now, thanks for all the help (the tegra driver in the archive makes lightdm end up in a restart loop though, i just uploaded the new tegra driver, lets see if that works)
<LetoThe2nd> ogra_: roger that
<ogra_> hmm
<ogra_> i assume /dev/sdd1 contains /boot ?
<LetoThe2nd> ogra_: i guess so, its what installer automagic created.
<ogra_> right
<ogra_> LetoThe2nd, bug 872525
<ubot2> Launchpad bug 872525 in partman-uboot "No option for u-boot partition on armel omap/omap4 platforms" [Medium,Triaged] https://launchpad.net/bugs/872525
<LetoThe2nd> ogra_: want me to try gruemasters suggestion?
<ogra_> that would be helpful
<ogra_> if that works i'll take a look at how we can default to that setting with a default preseed entry
<LetoThe2nd> ogra_: will take some time, probably about an hour. gonna report back then.
<ogra_> great, thanks
 * ogra_ will meanwhile take a look at the preinstalled server images
<TheMuso> ogra_: What was the reason for changing the panda images from preinstalled to live?
<ogra_> TheMuso, bad user experience due to bad I/O on SD cards
<ogra_> TheMuso, and the fact that it takes some effort to maintain the preinstalled stuff separately ... with the switch to live we just use what all other arches use
 * TheMuso nods.
<ogra_> which reminds me ...
 * ogra_ needs to update the alsa UCM stuff for the pandaboard, seems they renamed the device *AGAIN* !
<TheMuso> UCM stuff is still very much in development it seems.
<ogra_> i hope they run out of names at some point
<ogra_> well, it worked (kind of) in precise and oneiric on the panda and the ac100
<TheMuso> Well I'll be able to help with testing at least... Jason got panda boards for all desktopt team members, so as soon as I get a USB drive box, my panda will be running quantal.
<ogra_> yippie !
<TheMuso> I probably still need to get extra bits, as I'd like to try and test 5.1 HDMI audio if possible. Got a stereo HDMI monitor, but I'd rather make sure everything works.
<TheMuso> ogra_: And are the gstreamer bits for omap4 available in precise? I see there is a driver via jockey, but what about the rest?
<ogra_> no, TI didnt make them available for the kernel we have in precise
<TheMuso> Shame.
<ogra_> there is a TI PPA that has them and an unsupported TI kernel package
<TheMuso> Ah ok.
<janimo> ogra_, \o/ for the final tegra graphics drivers!
<ogra_> well, lets see if they work :)
<ogra_> they already built, waiting for the publisher
<janimo> let's see how the new nvidia rebased kernel works, there may be regressions compared to precise
<ogra_> there surely is an issue with the alsa parts
<ogra_> i see a lot related messages
<janimo> marvin24, I went ahead and rebased our packaging tree (so your patches included in last package) on nvidia's l4t-15 branch
<janimo> I'll do a new rebase or cherry-picking for the changes you have added since sometimes soon
<janimo> I do not use the ac100 enough to know what kernel things still need fixing, so am a bit surprised to see new commits still being added as if there were actual issues :)
<ogra_> "tegra-alc5632.0: only stereo is supported in I2S mode" is what i get over and over in dmesg
<ogra_> (until i run sudo alsa force-unload to quieten it)
<LetoThe2nd> ogra_: nope, does not help
<ogra_> ok
<ogra_> probably partman-uboot is completely missing or so
<ogra_> i'll inspect it, as i said ...
<LetoThe2nd> the choice item was labeled a bit different "use longest contiguous free space" or so, it didn't fix it.
<TheMuso> ogra_: I should have my USB box tomorrow, so plan to do a net install then, if I get the same problem I'll do some digging as well, that is if you don't get to it today.
<ogra_> janimo, oh, disregard the moaning about alsa, i didnt run the new kernel yet, it was not on todays image
<ogra_> TheMuso, great, thanks
<janimo> oh, so it may actually be much worse :)
<ogra_> lets see ... rebooting
<janimo> I just ran a simple zImage to see it boot till tarbgall installer
<TheMuso> ogra_: TO confirm, in d-i, do I mark the first partition on the SD card as bootable?
<ogra_> janimo, hmm, looks like it hangs in fsck
<ogra_> TheMuso, doesnt matter we dont run DOS ;)
<ogra_> janimo, yeah, definitely
<TheMuso> ogra_: So I just ignore the SD card at partitioning time?
<ogra_> janimo, now it prints a message: "rcu_sched_state detected stall  on CPU 1 (t=6000 jiffies)"
<ogra_> janimo, hmm second try works (still the same issue with lightdm constantly respawning though)
<janimo> ogra_, is this after a successful install with the previous kernel and ext2?
<ogra_> and the alsa messages are back as well
<ogra_> janimo, right, todays image
<janimo> can lightdm respawning be related to l4t or is this with fbdev?
<ogra_> then i installed the tegra driver, updated it ... and then pulled linux-ac100
<ogra_> well it started with l4t
<ogra_> (before i upgraded the kernel)
<ogra_> but it can indeed be a missing bit in our kernels
<ogra_> which the final driver uses
<ogra_> hmm, intresting, startx works
<ogra_> and opening a terminal crashes it ... then it spills about 2000 alsa errors on the consile
<ogra_> *console
 * ogra_ purges the nvidia driver
<ogra_> janimo, ok, without the driver i get lightdm to work, but still have the alsa errors (sound works though, its just extremely niosy in dmesg)
<janimo> ogra_, so it worked with the newest tegra driver and the previous kernel?
<ogra_> yes
<ogra_> err, no
<ogra_> sorry
<ogra_> Xorg.0.log only has a segfault, no further errors
<ogra_> janimo, for whatever reason my syslog is full of "fuse.ko: Invalig Argument"
<ogra_> *invalid
<ogra_> oh, i just noticed the new driver ships new udev rules and an upstart init script
<ogra_> SHRIEK !!!!!!!!!!!!!!!!!!!!!!!1111
<ogra_> first command in that initscript is: chmod 0666 /sys/power/state
<ogra_> oh, intresting ... all hardcoded sysfs paths in there have tegra3 in their pathname
<ogra_> seems even though it is a ventana package it expects tegra3 devices
<ogra_> janimo, hmm something is definitely weird with the fuse module
<ogra_> it complains that fuse is loaded already if gvfs tries to load it on desktop startup ... but lsmod disagrees
<janimo> ogra_, I'll do an install myself today or tomorrow and look at the issues that piled up.
<ogra_> k
<janimo> I need to start using the ac100 myself it has been just standing there doing nothing for a good while
<ogra_> i'll try to find out why the tegra driver fails ...
<ogra_> yeah, i moved to a shiny new desktop myself
<janimo> ogra_, so you're back on x86 again :)
<ogra_> didnt touch the ac100's for a while, quad core, 16G and a super fast SSD somewhat spoiled me :)
<janimo> mumble, mumble, kernel cross-compilation, mumble mumble
 * ogra_ even started plaing games again in the evenings
<ogra_> ya ya ... i'll set up a cross env some day
<janimo> I keep saying that for almost 2 years but I should probably get myself one of those fast systems too. I do too much building and that would help
<ogra_> atm i try to fiull my 3TB HDD with images and a debmirror ... iÃ'll surely add several kvm's and cross chroots
<janimo> ogra_, it is not much of a cross env, no need for qemu and other junk for kernel. Just cross-gcc and you're done, so a single apt-get install :)
<ogra_> well, i want to keem the host system completely clean and do all work in chroots
<ogra_> *keep
<janimo> for full package builds yes, chroots and whatnot is needed, but kernel builds are really simple
<ogra_> preferably having them tarred up and unpacking them on the fly to a tmpfs
<janimo> having fast ssd and lots of RAM allows such complicated setups I guess
<ogra_> somehow i cant get the system to use more than 9-10G of the ram ...
<ogra_> so i can eat the rest with tmpfses
<janimo> isn't there something like SETI at home but which eats RAM instead of CPU cycles? You should try that
<marvin24> <ogra_> "tegra-alc5632.0: only stereo is supported in I2S mode" is what i get over and over in dmesg
<ogra_> that should allow cross builds in minutes :)
<marvin24> or pull ;-)
<ogra_> marvin24, pull ?
<janimo> git pull?
<ogra_> oh, a fix !
<ogra_> great
<ogra_> i just blacklises all sound stuff for now ...
<ogra_> *blacklisted
<ogra_> concentrating on the xorg issue
<ogra_> i wonder if that driver is supposed to work with this kernel at all
<ogra_> startx actually gets me a full desktop but X crashes as soon as i click something
<janimo> marvin24, I tried cloning your tree again yesterday but gitorious would not let me. I'll try again these days
<ogra_> and all info i can get is "Segfault at 0x86"
<ogra_> in Xorg.0.log
 * marvin24 didn't tried the new driver yet
<marvin24> I only heard of troubles so far ...
<ogra_> so lets see how well hrw did his job ...
 * ogra_ installs gcc-arm-linux-gnueabihf for the first time evar 
<hrw> ;)
<hrw> ogra_: if you want to build !kernel then also 'apt-get install libc6-dev-armhf-cross'
<ogra_> will do
<janimo> ogra_, hmm I may have lied when telling you there's a single package needed. I remember hrw telling me I need that too but now I do not recall why it was needed for exactly
<ogra_> http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/
<ogra_> thats enough for me :)
<janimo> ogra_, you mean to build full debs not just zImages?
<janimo> ogra_, this is what I usually use debuild  -eDEB_BUILD_OPTIONS="parallel=3" -eskipabi=true -eskipmodule=true -eCROSS_COMPILE=arm-linux-gnueabihf-  -b -aarmhf -us -uc  -nc
<janimo> you can make the parallel much more I guess
<janimo> I also usually set tools=false in debian.*/rules.d/armhf so I don't have to cross install other deps for linux-tools
<janimo> but for quick testing I just build zImage
<ogra_> yeah
<ogra_> hmm, so our kernel doesnt have NVHDCP enabled
<ogra_> and there seem to be a few new NVMAP options to play with
<ogra_> oh, and we dont have /dev/nvram enabled at all
<ogra_> hmm, building definitely doesnt work as advertised
<ogra_> (cross building that is)
<ogra_> nope, cant make it build
<ogra_> aha, only works if CROSS_COMPILE is set
<ogra_> janimo, i think there was something added to the linux package scripts to automatically set that in ubuntu kernels when cross building a package ... are we missing a merge ?
<janimo> ogra_, CROSS_COMPILE needs setting in env when doing simple make zImage
<ogra_> janimo, it shouldnt for the package
<janimo> also in the debuild line I pasted above
<ogra_> yes, but not in hrw's howto
<janimo> not sure if we are missing something, I did not work on other arm kernel packages
<ogra_> and i think the kernel team enhanced the scripts to auto xport that var during package builds
<janimo> I know, no idea really I just stuck to what works and what I learned last year here: https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel
<janimo> ogra_, they may have done that, in which case I did not know about it to incorporate in our scripts
<janimo> I will if I find out :)
<ogra_> there was a ML discussion a while ago during precise
<janimo> I pasted that line to show what I used all the time and what worked for me for ac100 and armadaxp kernels too
<ogra_> right, that works here too (despite the fact that i dont like debuild and use dpkg-buildackage)
<ogra_> wow, that was fast (failed in tools since i didnt suppress them)
<ogra_> wow, i actually got all four cpu cores at 50Â°C ... havent seen them above 30 since i built that thing
<hrw> ;)
<hrw> curse m4 for lack of ifndef
<ogra_> grrr
<ogra_> i cant get past the failing tools
<ogra_> do_tools=false as documented everywhere doesnt seem to have any effect
<ogra_> oh CRAP !
<ogra_> so debian.linaro overrides all defaults ?
<ogra_> *SIGH*
<ogra_> real	5m49.016s
<ogra_> user	13m47.740s
<ogra_> sys	1m23.897s
<ogra_> nice !
<janimo> ogra_, did you only use parallel=3? user/real suggests something like that
<ogra_> =8
<janimo> or maybe kernel builds is more deb packaging and linking that parallelizable compilation
<ogra_> i thought 4 cores should be able to handle 8 threads :)
<janimo> ogra_, they do, but the last bits - the packaging ones - are likely only using 1 thread
<ogra_> indeed
<janimo> probalby with plain make zImage you'd get a much better ratio :)
<janimo> but anyway, nice to have such fast turnaround now
<ogra_> oh, definitely, but with 13min for a package build i wont complain :)
<janimo> 13 user, real was 5 no?
<ogra_> yep
<infinity> ahs3`: *poke*
<infinity> ahs3`: That python-greenlet patch probably shouldn't be using uname to set CFLAGS in setup.py, since that's depending on the buildd environment, rather than the target.
<infinity> ahs3`: (In our case, it'll just get set universally for armel/armhf, since all our machines have that uname, but it still seems sketchy in the case where that's not true)
<ahs3`> infinity: hrm.  is that the part that adds -fomit-frame-pointer?
<infinity> ahs3`: Yeah.
<infinity> ahs3`: I could just as easily be building on an armv5 machine with -mcpu=armv7-a, and that flag then wouldn't get set, though it should be.
<infinity> ahs3`: Seems harmless for the SRU and for our current buildds, but still inappropriate (IMO) for upstreaming.
<infinity> ahs3`: Then again, upstream seems to suffer that issue elsewhere too, so..
<ahs3`> infinity: right.  latest upstream has already moved well past this version and it's not needed there.  but, there are several other ARM patches in 0.3.4
<infinity> ahs3`: Mmkay.  Then it doesn't bug me *as* much.
<infinity> ahs3`: (I note that upstream makes the same mistake with a uname=i386 check, so at least it's consistently broken)
<ahs3`> infinity: well, and bumping versions for SRU is a no-no, yeah?
<infinity> ahs3`: I assume this omitting of frame pointeryness won't break armel while fixing armhf?
<ahs3`> infinity: lol.  oh, goody, we're consistently broken :)
<infinity> ahs3`: Yeah, bumping upstream versions is a no-no unless absolutely needed.  I'm much happier with the backported patch option, as long as it works.
<ahs3`> infinity: i don't believe this will hurt armel; this only shows up in armhf
<ahs3`> (the bug, that is)
<infinity> Except, wait...
<infinity> -fomit-frame-pointer is included by default in -O2 anyway.
<infinity> Is there somewhere else where this is being forced to -O0 or something?
<ahs3`> not that i ever found :(.  the only reason that's there is that it was not showing up on the gcc line when building
<ahs3`> i presumed that was being echoed correctly
<infinity> Right, it's in the default set.
<infinity> You'd need to use -fno-omit-frame-pointer to explicitly ask for the inverse.
<infinity> So, that part of the patch is probably a no-op.
<ahs3`> probably so; re-running the tests would confirm
<infinity> Anyhow, it's harmless either way, I'm not going to make anyone retest and reupload, if you know this version works.
<infinity> And if upstream no longer has that bit of code, all the better.
<ahs3`> it does.  tested on armadaxp, on precise
<ahs3`> yup, plus other ARM fixes that would be nice to have, but oh well
<infinity> Well, feel free to backport more fixes. :P
<infinity> Unless the new upstream is really just "nothing but more ARM fixes", then we can talk version bumps.
<infinity> ahs3`: For now, accepting this into proposed.
<ahs3`> infinity: thx.  unfortunately, it's a bunch more than just ARM stuff
<infinity> Well, even if the new upstream is "nothing but bugfixes with no new features", we could perhaps talk about that.
<infinity> But it's not even in quantal yet, so...
<infinity> We'll cross that bridge if anyone feels the urge to later.
<ahs3`> actually, it's already in quantal
<infinity> Is it?  I thought Q was 0.3.3... You were talking 0.3.4
<ahs3`> hrm.  lemme look.  i thought zul had gone to 0.3.4...
<infinity> Nope, and Debian's still at 0.3.3 as well.
<infinity> Bah, and the mips ASM is broken too.  Is that fixed in 0.3.4 as well?
<infinity> If so, I might just NMU the new upstream. :P
<ahs3`> d'oh.  yup.  0.3.3.
<ahs3`> lemme check the changelog.  i don't recall seeing mips fixes, but i wasn't looking for them
<infinity> platform/switch_mips_unix.h: In function 'slp_switch':
<infinity> platform/switch_mips_unix.h:43:1: error: $fp cannot be used in asm here
<infinity> error: command 'gcc' failed with exit status 1
<infinity> It's so lovely when people write assembly blind.
<infinity> (I can only assume it was blind, since it's pretty obviously broken)
<ahs3`> looks like the last mips change (at least in the switcher code) was in 2010 :(
<infinity> Yeah, I'm seeing that.
<infinity> So, something externally broke it.
<infinity> Oh well.
<infinity> I don't have any mips machines to test on, and I can't see obvious breakage at a glance.
<infinity> Can I just go on the record as saying that python modules with hand-tuned assembly are a bit of a giggle?
<zul> ahs3`:  3.3
<ahs3`> lol.  absolutely.  it is one of the more amusing bits of code i've seen
<ahs3`> zul: nod.  i got 0.3.4 stuck in my head for some reason
<infinity> Anyhow.  I might NMU ARM fixes into Debian, which would bring us in line (except for the dh_python2 switch), but that won't actually help the RCness in Debian, due to the mips breakage. :/
<infinity> And if ARM is fixed upstream in 0.3.4 anyway, that seems like it might be wasted effort on my part.
<infinity> Erk.
<infinity> ahs3`: Is the testsuite still disabled in precise due to this breakage?
<infinity> ahs3` / zul: I may prefer to see "turning the testsuite back on" as part of the SRU, to prove it's all better.
<ahs3`> infinity: dunno.  i don't think it was ever ENabled
<infinity> ahs3`: It's enabled in Debian, it's disabled in our packages because it was segfaulting on ARM.
<ahs3`> infinity: ah.  then you should be able to enable it again; that's what was used to test the patch
<infinity> ahs3`: Alternately, this package is too much of a mess for me to try to make sense of. :P
<infinity> ahs3`: If someone tests the output of the buildds, I'll just scream LA LA LA and ignore the testsuite still being off.
<ahs3`> infinity: fair enough.  testing we can do.
#ubuntu-arm 2012-07-19
<janimo> ogra_, you really should change that 30min estimation to 5min in the tarball unpacking message :)
 * janimo is installing today's ac100 image
<ogra_> janimo, heh, ok
<janimo> getting into X in the installer is noticably slower than in precise
<janimo> at one poits it's at console login as if no X is gonna start
<ogra_> the initrd somewhat takes longer
<ogra_> ubiquity-dm was always slow though
<janimo> this was after starting userland on root, not sure it was the initrd
<ogra_> lightdm is fine
<janimo> X seemed slow to paint
<ogra_> well, the time it takes from booting to the fsck messages
<ogra_> thats significantly longer ...
<ogra_> and i fear on all arches
<janimo> getting to fsck took longer a bit, but then another 2 min until X
<janimo> installer enocuntered unrecoverable error :(
 * janimo checks logs
<janimo> I wish there was a way of logging in/starting a shell to debug when this installer crashes
<janimo> 'a desktop session will be run so that you may investigate' but that too crashes
<ogra_> wow, my install worked fine OOTB here
<ogra_> which image did you use ? todays ?
<janimo> ogra_, today's yes
<ogra_> weird
<ogra_> no installer issues at all here
<ogra_> the screen doesnt wake up properly after DPMS kicked in though
<ogra_> (just noticed)
<ogra_> janimo, bug 1026577 ?
<ubot2> Launchpad bug 1026577 in ubiquity "ubiquity crashed with TypeError in _execute_child(): Can't convert 'list' object to str implicitly" [Critical,Fix released] https://launchpad.net/bugs/1026577
<ogra_> even though i didnt see it here, it is obviously in these images)
<ogra_> ah, no, ubi-partman
<ogra_> ignore me
<janimo> ogra_, how hacky/hard would it be to provide a login shell before the install is complete? Ubuntu has a live desktop with ubuntu user where you can look around at will
<ogra_> pretty hackish and hard
<ogra_> (and really nothing i want to invest time in)
<janimo> ogra_, what caused the crash last time was trying to use wifi, let's see what happens this time when I skip that
<ogra_> weird, worked all fine here
<janimo> ogra_, I agree then, if there is time to invest it should be towards unifying with the ubuntu live installer
<janimo> I kept pushing connect and it did not
<ogra_> the only issue i currently see is DPMS and plymouth
<janimo> if I connected from the NM icon in the panel it worked
<janimo> but then crashed
<ogra_> weird
<ogra_> the page doesnt automatically move forward after it connected
<janimo> oh now it went ahead did not even ask about wifi
<ogra_> but the button changes
<marvin24> ogra_: that's a tegrafb bug
<marvin24> switch to X and back may help
<ogra_> janimo, is that a freshly unpacked tarball or just the failed install rebooted
<janimo> ogra_, failed install rebooted
<ogra_> if its the failed one, debconf definitely keeps your input
<ogra_> so thats normal ...
<janimo> ok, now it installs
<janimo> still a bug but maybe it's in the logs somewhere
<ogra_> marvin24, thx, it does indeed
<ogra_> yeah
<ogra_> might be HW though
<marvin24> the nv guy seems to have given upon the console problems as it seem
<marvin24> I got no reply from him for a few days
 * ogra_ just built an lzma compressed kernel ... curious if that will work
<ogra_> marvin24, do you know of any source for a README or HOWTO what needs to be switched on in the kernel to make the binary driver work ?
<ogra_> i suspect our kernel still doesnt have everything needed and would like to find out if its a config prob
<marvin24> nv added a lot of options, yes
<marvin24> I guess some tegra_defconfig should be sufficient
<ogra_> is that documented anywhere ?
<ogra_> hmm, k
<marvin24> arch/arm/configs/...
<janimo> ogra_, maybe getting the kernel image from the L4T package and seeing what config it has enabled would help?
<ogra_> janimo, i would, if i could :)
<marvin24> is there a new l4t release?
<ogra_> nvidia downloads are completely shut down since the hack
<ogra_> marvin24, only R15 final
<janimo> marvin24, L4T 15 final of a week or so ago
<ogra_> i think you know about it
<janimo> lilstevie, said the actual download links still work, just the site frontend/logins is stopped
<ogra_> we already have it in quantal, but x fails
<janimo> it's just that we don't know the link URLs :)
<ogra_> janimo, well, doesnt help if i want to lok for a readme
<ogra_> i know the url
<janimo> ogra_, if there's a kernel image in the URL that may have configs already
<ogra_> but the README contained doesnt talk about kernels at all
<janimo> which we can compare with ours
<lilstevie> ogra_: I have most of the documentation on hand
<lilstevie> what is it about the kernel that you are interested in
<ogra_> yes, it might be in the softfloat package
<lilstevie> yeah
<lilstevie> itttt is
<lilstevie> but I also have the documentation package that is just the docs
<ogra_> lilstevie, on ac100 lightdm gots in a crash loop ... killing lightdm and running startx gets me a desktop but as soon as i click something it crashes
<ogra_> *goes
<lilstevie> quantal only?
<ogra_> yep
<ogra_> ABI12
<marvin24> ogra_: so we are left with tegra_android_defconfig
<lilstevie> hm
<ogra_> marvin24, hmm, android doesnt use the xerver, do they ?
<lilstevie> well as far as the docs say as long as you are using l4t-r15-rc tag it should be fine
<marvin24> no, but that's the only tegra2 config I found
<ogra_> is our kernel at that tag ?
<lilstevie> as of r15 they rolled the DC code to be a common base
<marvin24> ogra_: no, we are further in the future ;-)
<marvin24> rel-15r7
<marvin24> (branch)
<marvin24> tegra-15r7.1-android-4.0
<marvin24> tag
<janimo> marvin24, lilstevie actually with the last update we are at origin/l4t/l4t-r15
<janimo> I rebased on what I learned was very latest and recommended with L4T drivers by nvidia
<marvin24> janimo: so you stepped back?
<janimo> marvin24, is that back??
<marvin24> rel15r7 is 4 weeks old
<marvin24> l4t/l4t-r15 is 7 weeks old
<janimo> I hate nvidia tag/branch naming scheme
<marvin24> http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git
<marvin24> janimo: yes, this is very confusing
<janimo> marvin24, so 15r7 is the one that goes with L4T final?
<marvin24> I think they have different l4t and android branches
<lilstevie> they seem to maintain these things in parallel and not talk to eachother
<janimo> I thought from the most recent discussion with lilstevie that the branch I used was
<lilstevie> janimo: technically no
<janimo> oh well
<marvin24> l4t and android may have different branches, yes
<marvin24> I used the android one because it seemed to me that it has more fixes
<janimo> I tried avoiding the android branch for that reason
<janimo> by that reason being - it goes with L4T
<janimo> no idea what the diffs are
<marvin24> works fine here ...
<janimo> marvin24, this branch of yours is newer that what we had last week in ubuntu?
<lilstevie> I haven't seen the new hdmi stuff in the newer rel-15r7 code from android
<marvin24> mine is based on tegra-15r7.1-android-4.0
<marvin24> while you seem to have used tegra-l4t-r15-rc
<janimo> ogra_, so ac100 install finished just as usual the first thing it does is crashes and invokes apport
<ogra_> lol
<ogra_> well, if you had a ubiquity crash there is a core dump in /var/crash on first start
<ogra_> apport just picks that up
<ogra_> WOW !!!!!!
<ogra_> building the kernel lzma compressed saves 1MB !
<ogra_> if that actually works, i could leave plymouth ion the initrd and drop all the ugly diversion hackery
<ogra_> and it does !
<lilstevie> ogra_: I have been building my kernel lzma'd for a while now for size reasons
<ogra_> lilstevie, right, it was never clear if the ac100 fastboot can handle that
<marvin24> kernel decompresses the initrd
<ogra_> i had mixed results in the past (though testing initrds, not kernels)
<lilstevie> well the kernel decompressor code does it
<marvin24> fastboot only has the 2MB limit
<marvin24> so you may have ran into this problem
<ogra_> i had initrds failing with the old kernels when trying out other methods than gzip
<ogra_> (2.6.29 etc)
<marvin24> you need to select the decompressor in the kernel config
<ogra_> for the initrd it just needs to be enabled
<marvin24> older kernels didn't support so many (only gz and bz2 I think)
<ogra_> and we always had lzma available as inbitrd compression method
<ogra_> even in the kernels where iot didnt work
<ogra_> lilstevie, do you use any special cmdline options on your tablets to work with the r15 driver ?
<ogra_> vram or something alike
<lilstevie> no more than usual
<ogra_> hmm, k
<lilstevie> http://paste.ubuntu.com/1100098
<ogra_> vmalloc=128M video=tegrafb
<ogra_> do you use these normally ?
<lilstevie> but that is what the bootloader passes up
<lilstevie> yes
<lilstevie> almost the entire commandline is from the bootloader
<ogra_> i assume that doesnt fix the DPMS issues i see here "no_console_suspend=1" ...
<lilstevie> DPMS issues?
<ogra_> i need to switch to console after waking up from DPMS to get X back
<ogra_> els i end up with a black screen
<lilstevie> oh
<lilstevie> no I don't have that
<lilstevie> in fact switching to any tty means I don't come back :/
<ogra_> ah
<ogra_> janimo, oh, i get a crash massage as well, seems its plymouthd
<lilstevie> but I wake from DPMS fine
<janimo> ogra_, no coming back from suspend either here, can't seem to switch to any VT
<ogra_> yep
<janimo> ogra_, my initial ubi crash was indeed due to failing to connect NM, which crashed before that
<janimo> so this is clearly a bug unrelated to ac100 installer
<ogra_> yeah
<janimo> unfortunately not enough info in the coredump
 * ogra_ is more intrested in the plyouth segfaults though
<ogra_> though it seems that my diversions are so good that i cant properly revert them :(
<janimo> marvin24, I was just about to tell you to skip moving the framebuffer as it causes the toshiba logo to scroll uglily up
<janimo> but I see you have a change already there
<janimo> would be good to skip it even if not using uboot for above aesthetic issue
<ogra_> uglily eh ?
<ogra_> :)
<janimo> well, it does not scroll smoothly enough
<ogra_> ++ btw
<janimo> either we fix that or remove the scroll :)
<ogra_> yeah, it shouldnt move at all
<ogra_> it didnt in the past
<janimo> it's a new change in 3.1 kernels only, needed for nvidia devboards apparently, but maybe not at all for us
<ogra_> yeah
<LetoThe2nd> howdy! is there some "official" ubuntu arm kernel git tree? like what goes into the omap4 images?
<marvin24> janimo: I don't know why they did it
<marvin24> maybe to see the bootloader output
<marvin24> I can disable it
<marvin24> and re-enable when we have u-boot *and* some bl framebuffer addresss
<janimo> marvin24, probably disabling it completely makes sense for us indeed
 * janimo is wondering how hard it is reflashing the ac100 to have the original layout where it had an SOS partition
<janimo> debugging kernels would be easier that way
<infinity> janimo: Mine still has an SOS partition.  I guess you could clone mine?
<janimo> infinity, I even had the full factory dump of the ssd on my disk, but the process itself seemed convoluted
<janimo> involving lots of nvflash calls
<infinity> Everything involves lots of nvflash calls...
<janimo> or hadn editing of some files
<janimo> yes, but this with weired argas thatn usual
<janimo> of course it may have just been the regular Ncommander fearmongering at work and all is easy-peasy
 * janimo just remembers that ad-ridden wiki where the process was confusingly written down
<janimo> also ramconsole is great, that prompted me to think of having it available easily on the ac100
<janimo> infinity, also I'd probably need the exact model I have for the factory images
<janimo> infinity, which is the easiest out of the archive solution for creating arm rootfs from c86? Anything better than deprecated rootstock?
<janimo> but higher level than debootstrap
<janimo> I don't seem to see an easy (as in linaro-media-create) tool for saying make an armhf root tarball corresponding to xubuntu-desktop optionally including other packages or kernel packages
<infinity> janimo: live-build, though we have no nice wrappers to make it brain-dead.
<janimo> infinity, oh does it do cross-builds too?
<infinity> It can.  I've not tested it much, but I know Linaro uses it.
<janimo> hmm, I should probably ask them what they use to create the l-m-c tarballs
<infinity> Then again, you can just untar ubuntu-core, toss in /usr/bin/qemu-arm-static, and tailor it yourself quickly too. :P
<janimo> yes, the qemu + taylor it yourself bits what I hate
<janimo> :)
<janimo> I wonder if I am such a niche person with uncommon needs when I keep complaining about our build tools in general :)
<infinity> janimo: Well, what you want can be done with live-build, I just don't find it "easy" to quickly tailor up something non-standard.
<infinity> janimo: But, then again, I don't think any tool is easier than "chroot in and make it how you want it".  Scripting that it only worth it if you do the same thing over and over.
<infinity> s/it only/is only/
<janimo> infinity, well not very non-standard mind you, getting a xubuntu-desktop is quite a common use case I'd say
<infinity> Well, then you also said "optionally including other packages". ;)
<infinity> But, anything that isn't a base image set is "custom" in my mind.
<janimo> infinity, well what I did today was a chroot indeed, via mk-sbuild just because that seems a nice enough wrapper that handles cross arch without me knowing what the hell is exactly going on behind the scenes
<janimo> the whole debootstrap --foreign and 2 stages stuff is not something I want to learn about right now
<infinity> The only problem with mk-sbuild is that it does a few schroot-specific things to your chroot, plus adding some buildd cruft you don't need.
<infinity> Otherwise, yeah, that works.
<infinity> (But you could have started with core, which would save you from the --foreign business)
<janimo> infinity, well yes, extra packages is custom but well within what an apt call can do and common enough to warrant a tool. But yes, I am whining
<infinity> I suppose I just don't see how "chroot foo/ apt-get -y install xubuntu-desktop^" is any harder than trying to convince a tool to do that for you.
<janimo> as always, I would be content with good docs if tools are lacking, but somehow those too are non-existent, too dense or hard to find
<janimo> infinity, the cross-build part is where I am lost as I never did that
<janimo> and having read of xapt, dpkg-cross and a few other tools that in my mind overlap in functionality I got non-the-wiser
<infinity> There's no cross involved in the above.
<infinity> Just emulation.
<infinity> Which is also how live-build and higher level tools work.
<janimo> infinity, where does qemu-arm-static get involved?
<infinity> And mk-sbuild, for that matter.
<infinity> janimo: You just copy it into the chroot to /usr/bin
<janimo> yes, I saw ps whosing qemu while running mk-sbuild
<janimo> hmm, and then everything just gets ran by it?
 * janimo must try
<infinity> So, "untar core chroot/ && cp /usr/bin/qemu-arm-static chroot/usr/bin/ && chroot chroot su -"
<infinity> janimo: If you install qemu-user-static on the host, binfmt_misc gets magically configured to throw all your non-native binaries at emulators.
<infinity> janimo: So, as long as your current root has the emulator, you win.
<janimo> yes, it has it, let's see
<infinity> (since interpreters are found by path, whether it's an emulator, ld.so, /bin/sh, etc)
<janimo> infinity, ok, running now in the chroot. I needed to create and chroot into it as sudo since it would not untar /dev nodes otherwise
<infinity> janimo: Well, yes.  The above assumed you were root.
#ubuntu-arm 2012-07-20
<TheMuso> So... I think I tracked down why omap*/panda aren't bootable after a net install in quantal... The omap and omap4 keywords are missing from the flash-kernel-installer sub-architecture package field.
<TheMuso> So the package doesn't get installed into the d-i environment when net-retriever/anna is run.
<TheMuso> Now... To work out how I can test my theory without uploading. I only want to do a flash-kernel upload if I *know* that is the fix. Hrm.
<infinity> TheMuso: You could tear apart the d-i initrd and make your changes to f-k-i manually.
<infinity> TheMuso: Though, I'm not sure you're right in this case.  f-k-i in 3.0 doesn't seem to have ANY board logic at all, it just calls flash-kernel in the target.
<infinity> TheMuso: And it apparently works for other boards (like highbank and armadaxp).
<TheMuso> infinity: I was thinking along those lines, but that doesn't really test whether anna will end up installing the package into d-i.
<TheMuso> Looking at a syslog from a precise d-i install, flash-kernel-installer gets installed. Quantal, it doesn't. So the package doesn't even get installed into d-i for flash-kernel to be run in the first place.
<infinity> TheMuso: Oh!, you're talking XB-Subarchitecture:
<TheMuso> Yes.
<infinity> Right, sorry, I thought you were talking board logic, like in the 2.0 f-k-i.
<TheMuso> No, sorry I should probably have been slightly clearer with which package field I meant.
<infinity> I'd say that the XB-Subarchitecture: change would be correct even if it doesn't fix your bug, so upload away.
<TheMuso> Thats what I'm thinking too. The worst that will happen is that it doesn't work.
<infinity> TheMuso: While you're there, feel free to steal https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1026780 from ogra too. :P
<ubot2> Ubuntu bug 1026780 in flash-kernel "3.0~rc.4ubuntu4 doesn't honor bootargs from /boot/boot.script anymore" [Undecided,New]
<infinity> TheMuso: And welcome to ARM porting!  (sucker)
<TheMuso> Sure, will take care of it. :)
<TheMuso> And since powerpc is not really going anywhere any more, I need another non-x86 architecture to sink my teath into.
<infinity> BenC might disagree with you.
<TheMuso> ...and Jason my manager got pandaboards for all desktop team members, so I want to get quantla set up.
<TheMuso> Well, for desktop use. Thats all I cared about for powerpc.
<TheMuso> quantal even
<infinity> I think Ben's company is targetting desktop use as well as server.
<TheMuso> Oh ok.
<infinity> He certainly wastes a lot of time fixing FTBFS issues in desktop stuff.
<infinity> So, there must be a reason for that. :P
<TheMuso> True.
<infinity> Or maybe he's just doing it to prove the port is healthy.
<infinity> Which is fair.
<TheMuso> Well I still ahve a love of non-x86 stuff.
<infinity> Since every time some part of ubuntu-desktop is broken, someone screams "oh god, the port is shit, we should drop it", and I say "but, but, I run several powerpc servers, and that stuff all works fine."
<infinity> If you've given up on it, though, you can send me your powerstation. ;)
<TheMuso> heh
<TheMuso> Dunno, I am still undecided.
<infinity> I'd use mine for desktop stuff, but I've been too lazy to buy a sound card for it.
<infinity> (And by 'desktop stuff', I mean I'd keep using it as a server, but also watch movies on it, hence the need for sound)
<infinity> I wonder if anyone still makes decent but cheap PCI sound cards, or if I'm stuck buying some professionally overengineered whizbang thing because every new computer ships with onboard sound that's "good enough".
<TheMuso> My problem is that its too noisy.
<TheMuso> So I only run it when I want to do powerpc work.
<infinity> It is a bit of a wind tunnel, as designed.  That could be fixed.
<TheMuso> I know its as designed.
<infinity> Say, did you ever try out SATA drives in yours to see if the SAS controller in there was nearline SATA friendly?
<infinity> I need to try that sometime, but I don't really want to buy a drive just to find out it doesn't work.
<TheMuso> No, haven't tried, as I don't have any caddies suitable for mounting another drive. I could remove the existing drive, but whats the point in only having one drive when I could have more.
<infinity> I bought a bunch of rails from an eBay vendor for 3 bucks a pop.
<TheMuso> Are they generic drive rails?
<infinity> It's a standard IBM part, and they make clones of the part.
<TheMuso> Ah ok.
<infinity> 13-051054
<TheMuso> Anyway as to the bug above, would the user's /boot/boot.script overwrite the flash-kernel boot script wholesale, or are we wanting to do some funky stuff to encorporate both of them?
<infinity> Googling that part number should to the trick.  Or eBaying it.
<TheMuso> Yep.
<infinity> boot.scr should be generated from a combination of flash-kernel's internal logic and the user's boot.script.  Ish.
<infinity> That's more or less how it worked in 2.0, IIRC.
<infinity> Anyhow, I was going to fix it later (or let Oli get to it), so don't stress about it being a prerequisite for uploading your 2-word fix or anything. :P
<TheMuso> Hrm ok.
<infinity> I need to do some mangling in the same general area (cmdline args) to make f-k-i play nicely with d-i in the same way grub-installer does.
<infinity> So, you can just pretend we never had this conversation, if you prefer.
<TheMuso> I'm just looking at flash-kernel from precise to see how it handled this usecase...
<infinity> Have fun with that.  I think I might shower, and go remind myself what women look like.
<TheMuso> Heh ok.
<TheMuso> infinity: Meh I'm not going to worry about that bug, I have other things I want to do and I want to get my board up for some pulse 2.1 testing...
<TheMuso> Doesn't scratch my itch. :p
<janimo> ogra_, TheMuso is flash-kernel now more in sync with debian than it used to?
<janimo> I knew at one point they were very diverged
<ogra_> janimo, yes, we base on the latest in deabin now
<ogra_> *debian
<sveinse> I don't know if this is the right channel for this: but how do you handle backport in terms for versioning? I have a natty host, which needed boost1.46. So I took the precise sources and compiled it for natty. Time goes and its time to dist-upgrade to precise. However boost refuses to upgrade as it's the same version the one I compiled for natty. What version number should boost backported...
<sveinse> ...to natty have?
<sveinse> Any of you guys here had any problems cross compiling x-loader with precise -4.5 compiler? Mine compiles and runs fine with natty host, compiles fine with precise host as well, but won't start
<sveinse> (this is for omap3530)
<ogra_> sveinse, we usually dont cross build u-boot, we only take what linaro gives us usually, probably ask in #linaro
<sveinse> ogra_, thanks. Keeping it cool by not cross compiling then :P
<ogra_> sveinse, oh, and on a sidenote we dont use x-loader anymore since precise
<ogra_> we use the upstream u-boot-spl
<sveinse> ogra_: oh, and no u-boot either then I suppose
<ogra_> we use uboot but u-boot-spl instead of xloader
<sveinse> why, if I may ask
<ogra_> ease of maintenance
<ogra_> u-boot-spl is maintained inside the u-boot tree
<ogra_> x-loader was always a fork with just reduced functionallity
<sveinse> interesting. Technically, is u-boot and u-boot-spl compiled from the same project then?
<ogra_> yes, same source code tress
<ogra_> *tree
<sveinse> nice. I'd consider using u-boot-spl just to remove the extra x-loader package...
<ogra_> well, thats what we do in ubuntu
 * sveinse apt-get source u-boot
<LetoThe2nd> ogra_: i just realized canonical is actually working on MetalAsAService: https://tbe.taleo.net/NA3/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=502
<LetoThe2nd> ogra_: it offers me to build MAAS :)
<ogra_> sure, we're working on that since a year :)
<ogra_> oh, a historical day !
<LetoThe2nd> ogra_: ?
<ogra_> microsoft had negative stock numbers for the first time in its history today :)
<LetoThe2nd> ah, i thought you are finally getting loud with that project :)
<ogra_> heh, it has been promoted a lot over the last half year
 * LetoThe2nd didn't read about it, neither in metalhammer nor rockhard.
<ogra_> btw, i just inspected netboot, thats never gonna work (and i wonder why it ever did) there is no partition at all on the SD
<LetoThe2nd> hehe.
<ogra_> the old flash-kernel seems to have had very bad hacks to work around this
 * ogra_ will try to add a partition to the images
<LetoThe2nd> sounds like a plan, then.
<sveinse> rsalveti: You there?
<sveinse> Do you recall bug 813018 by any chance?
<ubot2> Launchpad bug 813018 in x-loader "gcc 4.5 breaks overo in latest x-loader (1.5.1)" [Medium,Confirmed] https://launchpad.net/bugs/813018
<sveinse> I think I hit this one when changing from natty build host (w/arm-linux-gnueabi-gcc-4.5.2-8ubuntu3cross1.47) to precise build host (w/arm-linux-gnueabi-gcc-4.5.3-12ubuntu2cross1.61)
<sveinse> Why did ubuntu decide on naming compilers as gcc-4.5? It creates just soo many hacks and ineffcients solutions, as very many scripts rely on $(CROSS_COMPILE)gcc (including the kernel)
<ogra_> sveinse, the default binary is always /usr/bin/gcc
<ogra_> (being a link to the gcc-4.x binary used in a release)
<sveinse> ogra_: My point was directed at the nomenclature for arm-linux-gnueabi-gcc-4.x. IMHO arm-linux-gnueabi-4.x-gcc would create less friction
<sveinse> well, it was a sigh, nothing more
<janimo> marvin24, do you know what happens in unified tegra kernels with errata handling? Seems to me some or all are hard-configured in the build, but would need runtime detection when run on multiple possible targets
<sveinse> Does arm-linux-gnueabi-gcc have --sysroot support on precise? (well technically its ld that needs to support it) It wasn't on natty.
<marvin24> janimo: there is no runtime detection for most erratas yet
<marvin24> I guess there will never be
<marvin24> you can only build kernels for a specific soc
<janimo> marvin24, I guess that adds overhead or suboptimal performance to chips unaffected by some?
<marvin24> yes, I think so
<marvin24> there was a discussion about this some time ago on the arm list
<janimo> but could be done by runtime patching I guess when booting up
<marvin24> if you want to get nailed, you could propose it ...
<janimo> ogra_, do you also have touchpad not working on the ac100 with latest install?
<janimo> marvin24, heh I was just wondering aloud, I am not even thinking on taking up such work :)
 * marvin24 hints janimo to the F9 key
<ogra_> janimo, works fine here
<janimo> ah the F9 key which I keep forgetting about :)
 * janimo will check ASAP
<Lopako> Hi all, I'm working with a few small ARM boards, currently focusing on the Gumstix Overo, although I'm pretty much a beginner at this level.
<Lopako> I've been having a little trouble (and a lot of confusion) trying to get an Ubuntu bootable sd card up and running for the Overo, and was hoping someone here could help clear up some things
<Lopako> Instructions I've found, pretty much all use the rootfs utility
<Lopako> *sorry, rootstock utility
<Lopako> to make the rootfs for an ubuntu distribution
<Lopako> but that's deprecated now, and they recommend using Ubuntu-Core for your rootfs
<Lopako> I guess my first specific question is what is the difference between the boot files (MLO, u-boot.bin, and the uImage kernel) on the hardware's site (gumstix.org), and the boot files with the same names on the ports.ubuntu.com site?
<Lopako> my second concern is about the hardware specific firmware and modules:
<Lopako> are they tied to the specific kernel used?
<Lopako> and if so, how can I figure out the version of the kernel they need, and the version I have?
<Lopako> any insight is greatly appreciated, thanks
<infinity> Lopako: Since we don't provide either a kernel or a bootloader for that device, the difference between our MLO/uBoot/uImage and theirs would be that "theirs works".
<infinity> Lopako: Oh, unless it's one of the OMAP3 variants.
<infinity> Lopako: In which case, I'd recommend just using our -omap images and seeing if that works.
<Lopako> yeah, it's an OMAP3
<infinity> Right, then.  Our images might Just Work.  Unless it needs drivers we don't/can't ship.
<infinity> Not having the hardware myself, I can't be wildly helpful.
<infinity> But have you tried just blatting our of our images to an SD and seeing what happens?
<Lopako> okay ... so the "-omap images" you're talking about are the full system SD card images? (vs. just the rootfs)
<Lopako> not yet, I was hoping to use a more lightweight version than the desktop image (which I used for a PandaBoard I'm also working with)
<infinity> Yeah.
<infinity> You could grab the server image.
<Lopako> ok
<infinity> It's large in size, but only because it has a package pool on it.  The actual installed system is tiny.
<Lopako> are all the current preinstalled images armhf?
<infinity> Lopako: Yes.
<infinity> Lopako: You almost certainly want armhf, unless you have some whacky obscure armel binary you just can't live without.
<Lopako> mk, the armhf vs armel choice still trips me up sometimes, I must have reread wiki pages on them 10 times this week
<infinity> Lopako: armhf = the new hotness
<infinity> Lopako: armel = binary compatible with older stuff, but slower and unsupported in the future
<Lopako> my end goal is to get software (ROS) on the Overo that's gonna have lots of dependencies which I'm worried about
<Lopako> haha
<Lopako> gotcha
<Lopako> btw, thank you for your help, infinity
<infinity> Is this software from some third-party that distributes binaries?
<infinity> Cause if it's from source (or in the Ubuntu archive), armhf won't be a problem at all.
<infinity> If it's from a third-party, lean on them to fix their crap, if they don't have an armhf build. :P
<infinity> Cause all future ARM ports for major distros are moving to armhf.
<Lopako> it's a big system of packages, most of them source, but often having system dependencies that can be tricky
<Lopako> how hard is it to make that move?
<infinity> Lopako: Well, not harder for armhf than armel.
<infinity> Lopako: The system deps should all be there, we built the entire archive for armhf.
<infinity> Lopako: And building from source is, well, the same on either.
<Lopako> okay, that's good to know
<Lopako> I'm interning for the company responsible for most of the core stuff, so this will be good to sell them on getting with the future =)
<Lopako> Just to double-check my understanding, if there's a library I need that has an armel binary, but no armhf binary in the archives, it should be fairly simple /compatible to built the source for armhf?
<infinity> Yes, but I doubt you'll find that situation.
<infinity> Our archive coverage was pretty good.
<infinity> Well, more to the point, you won't find anything that is buildable, but not in the archive. :P
<infinity> The only reason it wouldn't be is if it failed to build.
<Lopako> oo, k
<Lopako> thanks
#ubuntu-arm 2012-07-21
<jhobbs>  /wg 9
#ubuntu-arm 2013-07-15
<twb`> OK, never mind, I found the problem.  I turned off the journal on my SD card's ext4 filesystem, because my system never crashes, so it'll be fine, right?  Turns out, this trips a kernel bug when I try to download web comics onto it.  The similar fusker script didn't trip it last weekend - go figure.
<twb`> So I'll just go without webcomics for now.
<twb> [   95.907718] BUG: scheduling while atomic: python/1234/0xfffffffc
<lilstevie> twb, the one running windows isn't a transformer :p
<lilstevie> and is hardware identical (except the windows key and lcd) to the tf700
<twb> k
<twb> If I walked down to officeworks at lunch and dropped $900 on the current android tf, is your stuff set to flash it and make it all sexy and ubuntu? ;-)
<lilstevie> nope
<twb> Aw.
<lilstevie> I haven't done any work for tf recently
<lilstevie> been too busy
<twb> Are you working on anything, or just school?
<lilstevie> I moved house, and have no internet at the new house
<twb> I had no internet for three weeks just because the wire fell out of the cabinet in the street or something
<twb> it took that long for the telco man to come look at it
<lilstevie> we are having a little bit of difficulty getting the ftth connected
<lilstevie> cause our landlord is dragging their hands on getting the paperwork signed for connection
<twb> Bleh
<twb> At least ftth is an option for you
<lilstevie> they told us they signed and returned the paperwork 2 weeks ago
<lilstevie> option? there is no option, it is ftth or nothing
<lilstevie> no copper here
<twb> I dunno why you'd want copper, unless it's brand new and probably not even then
<twb> I'm assuming there are competing retailers for FTTH subscriptions
<lilstevie> heh, it isn't a matter of wanting copper, it is a matter of wanting anything for internet
<lilstevie> only 5
<twb> lilstevie: get a 3g dongle with prepaid data sim
<lilstevie> twb, that is what I'm using right now
<lilstevie> but 3g data is horrendously overpriced
<twb> just stop using facebook :P
<lilstevie> compared to my $40/m unmetered adsl2+
<lilstevie> twb, at the moment, I've stopped everything except irc
<twb> That's cheap for unmetered.
<lilstevie> that was cheap for unmetered yes
<twb> I'm still paying $80/200G/mo from internode
<lilstevie> internode are who we are going with for ftth
<lilstevie> but it is fairly pricey
<twb> Well iinetnode
<lilstevie> heh
<lilstevie> iiBorg
<twb> Since they drove up to simon's house with a truck full of money
<lilstevie> they parked the cube in his driveway and assimilated him
<lilstevie> http://www.internode.on.net/residential/fibre_to_the_home/estates/ but pretty much the best deal
<lilstevie> other options involve peak/offpeak which is bleh
<lilstevie> or 200GB quotas on 100/40
<lilstevie> or in the case of iPrimus waving your right to the CSG
<twb> I wonder if like electricity, you can get credits by providing internet back into the network
<lilstevie> hah
<twb> by hosting usenet and bittorrent and deb mirrors
<lilstevie> with an upload double that of my old download I'd happily do that
<lilstevie> but instead they charge you both ways
<twb> It's only going to be worse when libs get in and make me get fttc
<twb> I notice the exchange that's four doors down from me, has been sold
<lilstevie> "when the libs get in" I would have agreed 2 weeks ago, but we are looking at a much closer contest these days
<lilstevie> or at least a minority government
<lilstevie> some of the independents may help keep your ftth dream alive
<twb> TBH I haven't been paying attention
<twb> I don't know how to work our telly so I only get local news when someone from .ca or .uk asks me about it
<lilstevie> twb, lol
<ashes> hello
<ashes> have any of you use linux to control a DC motor?
<ashes> or if linux can be used to control a DC motor in any capacity... i need pulse width modulation to control speed
<maxinux> can linux - yes
<maxinux> http://beaglebone.cameon.net/home/using-pwm-outputs
<ashes> very interesting
<ashes> i own a trim slice, so i guess i can't use that
<ashes> it would also be cool to use linux for a lithium battery management system
<ashes> mm
<ashes> one problem with the beagleboard and what i want to do. i have a 48 volt electric bike with a 500 watt motor
<ashes> it can spike to 30-40 amps at startup
<ashes> i don't think the beagleboard can handle that
<ashes> so its pwm would only work with small motors or lights
<twb> "lithium battery management system" -- as in, the firmware that stops the thing from discharging all at once, overcharging, &c?
<twb> I'm not sure I want something as hairy as linux in charge of that.
<ashes> is suppose
<ashes> i suppose
<twb> I'm actually not sure you'd be able to reflash their firmware without some regulatory body clapping you in irons
<ashes> i am working on a piece of art basically. i bought a used $500 500 watt, 48 volt, electric moped (it has both a motor and pedals)
<twb> Ah, so you're not going to be sitting on it when it explodes :-)
<ashes> i have dropped another $1000 on it for new batteries, lights, wire, etc
<ashes> i upgraded the wire to 10 gauge, and gained 10% speed
<ashes> anyway
<ashes> i don't care if i spend $20,000 on a bike that is worth $800
<ashes> because i am learning as i go
<twb> I like my Gazelle Toer Populair, but it's unassisted
<ashes> i want a ebike that can do 110 kmph, and uses open source software
<ashes> i plan to overvolt 2000 watts of motors
<twb> Anything can do 110kmph if you drop it from high enough :-)
<ashes> i want motors on both wheels
<twb> http://www.cyber.com.au/~twb/doc/bike.txt are my bike notes, but I didn't cover any electric bits
<twb> But I think the power train of a bike is pretty embedded -- linux doesn't deal well with systems with <4MB each of volatile and non-volatile storage
<twb> You could certainly build a linux-based trip computer or entertainment system for the pillion passenger
<ashes> also
<ashes> the battery pack is 48 volts, and there is a 48 to 12 volt converter
<ashes> my brother, an electrician, says the loss should be minimal. i am willing to get a dedicated 12 volt pack for the lights
<ashes> i suspect the converter loses volts
<ashes> simply upgrading the 48 volt wiring from 16 gauge to 10 gauge got me a 10% speed increase
<ashes> the factory used many sizes of wires
<twb> https://en.wikipedia.org/wiki/Light_electric_vehicle says an "e-bike" can do up to 45km/h, if it does up to 80km/h it's an "e-motorcycle" and is subject to stricter DMV regulation (e.g. you need to wear a motorbike helmet)
<ashes> in canada it's a pedal bike without a gasoline engine, so it's legally a bicycle
<twb> Ah, OK
<twb> There's legal info in that page, too
<ashes> ok
<twb> It says you can't do more than 32km/h in canada except in alberta where you can do 35km/h
<ashes> yes, and i can dispute that i am going downhill
<twb> Righto.
<ashes> my bike does 45kmph
<twb> I assumed you wanted to do 110km/h on a flat plane with no wind
<twb> At STP and all that
<ashes> i hope police have better things to do than stop me for riding too fast in the bike lane
<twb> Pfft.  They pull me up when I'm walking home, make me show my hands to prove I have not been spraying graffiti
<ashes> i used to play snooker after the place closed, for free, and would walk home at 3am. i would get stopped by police every night, until i stopped walking in the small streets
<ashes> now i walk on major streets if i can
<ashes> police are less likely to stop someone on a major street because it disturbs traffic
<ashes> with my ebike, i am trying to develop 'ideal practice', mostly for soldering
<ashes> i get conflicting advice
<ashes> the guy at NAPA wants me to buy cheap stuff. my brother is an electrician, and he's worse
<ashes> i want ideal
<ashes> money is no object for this project
<ashes> i'm not rich, but i don't have a wife or children
<ashes> so far, my best ideal, is to strip, flux, tin wire. carefully crimp the connector on the wire for full contact
<ashes> solder the wire to the contact, and then insulate it
<redtape|renegade> Mail-order product available in respondable email #ads (AUG ~13} :::: http://www.fanlesstech.com/2013/07/utilite-quad-core-arm-linux-desktop.html  ::
<maxinux> i would have been more interested w/o the spam
<redtape|renegade> leaves.
#ubuntu-arm 2013-07-16
<mijk> hi
<mijk> I'm having trouble install quake using game-data-manager
<mijk> I'm trynig to point to the folder where the PAK files are but it still won't work
#ubuntu-arm 2013-07-17
<matheus> hi, I want to know if is possible to install ubuntu 12.04 server in a ARMÂ® Cortexâ¢-A7 Dual-Core
<matheus> I want to install ubuntu 12.04 server in the cubieboard with ARMÂ® Cortexâ¢-A7 Dual-Core. Is that possible?
<yokotest321>  i need some help crosscompiling a library for the arm platform. I am getting errors while compiling the library I get following error during crosscompile:syslex.l:31:21: fatal error: sysinfo.h: No such file or directory compilation terminated. make[2]: *** [syslex.o] Error 1 following is the config.log file : http://pastebin.com/eezqmJ9d and following is the install script : http://pastebin.com/fAErAqSQ
<yokotest321> trying to compile inside virtualbox machine
<rbasak> Try installing libc6-dev:<arch> if you haven't already. Eg. libc6-dev:armhf
<yokotest321> rbasak: does my ,/configure command looks ok in the install script? thanks for your help
<rbasak> I'm not sure, sorry. I don't see anything that's obviously wrong.
<yokotest321> rbasak: so on my development machine(virtualbox) i should install the libc6-dev correct?
<rbasak> You probably want to use /usr/include/arm-linux-gnueabihf/sys/sysinfo.h though, which is architecture specific. You should be able to install it inside your VM even though your machine isn't armhf thanks to multiarch.
<rbasak> No, you specifically want libc6-dev:armhf
<rbasak> https://help.ubuntu.com/community/MultiArch
<rbasak> https://wiki.ubuntu.com/MultiarchSpec
<rbasak> https://wiki.ubuntu.com/MultiarchSpec#apt_sources
<rbasak> You want a line like "deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports precise main universe" in /etc/apt/sources.list. Then you should be able to "apt-get update && apt-get install libc6-dev:armhf". Replace precise with whichever release you're using.
<rbasak> I hope that helps. I may be completely off the mark, but doing that shouldn't cause any harm.
<yokotest321> rbasak: how abt this package: sudo apt-get install libc6-dev-armhf-cross
<rbasak> yokotest321: quite possibly. There are multiple ways to do it, and I'm not sure which is the current best way
<yokotest321> rbasak: but i already have that file from the linaro toolchain which I am using for this crosscompilation.
<yokotest321> find . -name 'sysinfo*' ./arm-linux-gnueabihf/libc/usr/include/arm-linux-gnueabi/sys/sysinfo.h ./arm-linux-gnueabihf/libc/usr/include/arm-linux-gnueabihf/sys/sysinfo.h
<yokotest321> rbasak: so somehow its not able to locate that file during this compilation
<yokotest321> rbasak: if you don't mind could crosscheck once again my install script? how can I specify this libc path for this armhf toolchain to be used during this crosscompilation
<yokotest321> rbasak: hey, i am still having issues with that compilation error.
<yokotest321> rbasak: i tried modifying the ./configure command to ../binutils-2.21.1/configure --target=msp430 --host=${TARGET} --prefix=$INSTALL_PATH --host_configargs=${EXT_INCLUDE}
<yokotest321> rbasak: where EXT_INCLUDE='-I${TOOLCHAINDIR}/${TARGET}/libc/usr/include -L${TOOLCHAINDIR}/${TARGET}/libc/usr/lib'
#ubuntu-arm 2013-07-18
<drasko_> hi all, I am trying to compile bootchart-litem and getting : /usr/include/arm-linux-gnueabihf/bits/fcntl2.h:51:24: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument ns
<drasko_> http://pastebin.com/uibA0YQB
<ppisati> ogra_: what did i had to add to preEnv.txt to make the installer start on serial?
<ppisati> ogra_: i recall there was a keyword or something
<ogra_> just a proper console= option shoudl be enough iirc
<ppisati> ogra_: never mind, i didn't see preEnv.txt-serial :P
<ogra_> :)
#ubuntu-arm 2013-07-19
<lenz> Hey! Anyone there?
<drasko_> on boot, linux hangs there: [    2.601529] drivers/rtc/hctosys.c: unable to open rtc device (rtc0), then waits for a long time before continuing boot
<ogra_> fix your kernel then :)
<over_> hello, anybody developing in c# with mono here ?
<canurabus> hi all. is it possible to dual boot ubuntu with android on a nexus 4?
<linuxperia> Hi. I am a big Fan of Ubuntu Linux and a Long Year user/coder/developer since "Ubuntu Warty Warthog". I buyed recently the Android 2.2 Smart Watch Phone "Z1" => http://www.youtube.com/watch?v=stRX0URpSkw and want now to port Ubuntu Linux Phone Edition to this ARM Smart Watch Phone. Would like to ask if anybody with experience here is willing to assist, advice and help me with Porting Ubuntu...
<linuxperia> ...Linux Phone Edition to this great ARM Mobile Smart Watch Phone. I have a little experience with porting Linux and OPIE to Sony Ericsson Xperia Mobile Phones including Cross Compiling the Kernel and the needed Drivers on the other hand i have zero experience with Android and need here Help to not break my new Smart Watch Phone.
<linuxperia> The SoC Chip is a ARM MTK6516 and i have all the needed Images and Data for debuging.
<AmEv> Any Tegra 2 guys available?
<srwarren> AmEv, yup
<AmEv> Nice.
<AmEv> Well, stuck on trying to get native Ubuntu booting on my tablet.
<AmEv> Toshbia Thrive.
<AmEv> I've had a full boot.img, but nothing ever displayed on my screen.
<AmEv> Any suggestions?
<srwarren> Not really; that platform isn't supported by the upstream kernel which is what I deal with
<AmEv> Ah.
<AmEv> We do have a partial port to UTouch, with a kernel, and it got to the home screen...
<AmEv> Well, I do know that lilstevie was one that got it booting on several Tegra 2 devices.
<srwarren> I always suggest porting upstream U-Boot and replacing the bootloader, but that can be dangerous
<AmEv> Well, I do (unoffically) have NVFlash access...
<srwarren> Oh, it might not be that bad then
<AmEv> "Unofficially" as in "Toshiba sent it to the trusted beta testers, who one trusts me enough not to blow up my personal tablet with it".
<AmEv> Still, I do see that lilstevie was working on porting uboot to the TF101... You hear by fluke Steve?
<AmEv> Oh, quick question: Is there a way to inject adbd into the rootfs and have it run?
#ubuntu-arm 2013-07-21
<hrw> 3.11-rc2 works on chromebook ;)
<mmenefee> hi all.  I've managed to compile a custom Raring kernel for the Nexus 7, but I'm a bit lost as to how to build and flash a new boot.img.  Can anyone point me to a good tutorial?  Think I understand the zImage part, but not how to build the new initrd.img...
#ubuntu-arm 2014-07-16
<akaWolf> hello! how do I build an armel rootfs from scratch?
<akaWolf> armhf*
<rbasak> akaWolf: look up "debootstrap". And perhaps qemu-user-static
<rbasak> Though armel was dropped now, in favour of armhf. Debian might be a better bet if you want armel.
<akaWolf> I want an armhf, sorry
<akaWolf> debootsrap is a automatically tool, I want to do it from scratch own hands.
<rbasak> Sounds like you want Linux From Scratch or something then, rather than Ubuntu.
<rbasak> Or if you want to do what debootstrap does but yourself, then the best thing to do is to look at the file. It's just a script.
<akaWolf> last, ok, thanks, I will look at this script.
<ndec> akaWolf: debootstrap doesn't 'build' rootfs. it assembles prebuilt binary packages
<BorgCuba> Hi, I try to build rk3066 kernel 3.0.8+ with g_serial but the device is not recognized
<BorgCuba> same for g_ether
<BorgCuba> here is my boot log: http://pastebin.com/DWrwTZnR
<BorgCuba> adding "_pcd->conn_en=1;" in dwc_otg_pcd_check_vbus_timer solved it, but why do I have to change this?
<BorgCuba> well, it enumerates as "0525:a4a7 Netchip Technology, Inc. Linux-USB Serial Gadget (CDC ACM mode)" but it doesnt work
#ubuntu-arm 2014-07-17
<semico> Hi,what is rcn-ee.net?
<k1l> semico: why do you ask that in here?
<semico> ...
<semico> I can download ubuntu-arm from this url
<semico> is it offical website or ?
#ubuntu-arm 2014-07-18
<kleptos> hey peeps, I'm trying to get a good video output for smplayer but xv sutters when fullscreen and opengl crashes
<Joseph_> http://paste.ubuntu.com/7815466/
<Joseph_> kindly help
<Martyn> Hey all...
<Martyn> Is there anyone on the arm dev team that's in Switzerland, Germany, or Lichtenstein?
<k1l_> there are, but they are asleep or drunk in a bar at 1am i think :)
<Martyn> Yeah, I was hoping someone might be awake still, I guess.
<Martyn> There is a candy/sweet that is only sold in Switzerland ( that I know of ) that a housemate of mine wants.   I won't be there until Feb/2015
<Martyn> And they won't ship internationally.  So, I figure if we have a developer in Switzerland... I might get them to order it for me, and then ship to Texas :)
<Martyn> ( http://www.domaco-shop.ch/Dr-Doolittles-Pastillen-Pink-Grapefruit-Dose-zu-70g )
<Martyn> These things are -addictive-
#ubuntu-arm 2015-07-14
<edupt> I have a zedboard, and I am using a ubuntu 12.04. I would like to use dongle wifi usb, but it is not working. Can someone help me?
<edupt> I need to update to 14.04 ?
<edupt> Are someone there?
<k1l> edupt: maybe you are affected by this: http://askubuntu.com/questions/451463/upgrade-of-12-04-4-lts-to-14-04-lts-fails-on-pandaboard
<k1l> is it an armel board?
<edupt> no it is a zedboard from xilinx
<edupt> k1l: my connection falls... sorry
#ubuntu-arm 2015-07-15
<edupt> Hi! I use the xilinux (ubuntu 12.04) because, I am using the ZedBoard. I would like use a dongle usb Wifi, but it is not working. I have the drivers installed. Can someone help me?
#ubuntu-arm 2016-07-20
<Amul_macho> Need to get Ubuntu on custom system woth
<Amul_macho> With Arm v6 processor 1g ram
<Amul_macho> Anybody alive btw?
<Amul_macho> Anybody alive?
<Amul_macho> Anybody alive ?
<Amul_macho> à®à®©à¯à®¤à¯à®¤à¯ à®µà®¾à®´?
<Amul_macho> Cualquier persona viva ?
<Amul_macho> Toute personne vivace ?
<Amul_macho> à¤à¥à¤ à¤­à¥ à¤à¤¿à¤à¤¦à¤¾ à¤¹à¥ ?
<Amul_macho> Ø²ÙØ¯Û Ú©ÙØ¦Û Ø¨Ú¾Û
<Amul_macho> Anybody alive?
<rbasak> !patience
<Amul_macho> !patience shows nothing
<Amul_macho> Keeping! patience from half an hour by the way
<Amul_macho> More than half
<rbasak> Half an hour is not long enough for a specialist question. You also haven't really asked a question. Please read up on IRC etiquette.
<Amul_macho> Got a custom system with SOC : BCM21553 with armv6 processor. Need to get Ubuntu on that!
<Amul_macho> Solution?
<Amul_macho> Or method?
<rbasak> armv6? Won't work unless you rebuild. Ubuntu is compiled for armv7.
<Amul_macho> Source code where?
<rbasak> Sorry, I don't have time to walk through this with you. The task is far from simple. If you're not sure what you need to do, you'll probably be working on it for weeks, or perhaps months. I suggest you find a consultant.
<Amul_macho> Hmm got to know there is something  called Ubuntu mate
<Amul_macho> !logs
<Amul_macho> !channel-logs > Amul_macho
<ogra_> try irclogs.ubuntu.com ;)
#ubuntu-arm 2016-07-23
<ali1234> where am i supposed to report bugs against the "official" rapsberry pi 2 image?
#ubuntu-arm 2017-07-19
<billmania> Where can I find ubuntu Server 16.04 for the Radxa Rock Pro, or the procedure for assembling an image for the Radxa?
#ubuntu-arm 2018-07-22
<rpiNEEDSHELP> Help
<rpiNEEDSHELP> !ops
<rpiNEEDSHELP> !bot
<rpiNEEDSHELP> !list
<rpihelpme> help 4 real
<rpihelpme> Iâm getting mad
<rpihelpme> popey.
<rpihelpme> this isnât a prank
<rpihelpme> i wonât do !ops anymore
<popey> This isn't how to get support
<popey> You are abusing people
<rpihelpme> am I?
<popey> We are volunteer community members
<rpihelpme> almost every1 else is afk
<popey> Don't demand out attention
<popey> Technically so am I. I'm sat on a beach!
<rpihelpme> i need help ASAP tho
<rpihelpme> oh sorry
<rpihelpme> im so sorry!
<popey> And having to deal with people pinging me on IRC
<rpihelpme> oh
<popey> Rather than spend time with my family
<rpihelpme> im sad now
<popey> I did tell you many times to stop
<rpihelpme> ok
<rpihelpme> i wont
<rpihelpme> i just needed help
<popey> If you want immediate support on demand, frankly pay for it.
<popey> We are volunteering our time
<popey> We don't owe you support
<rpihelpme> Iâm so soory
<rpihelpme> i didnât know u were volunteers
<rpihelpme> can u link me to forums tho?
<popey> I recommend askubuntu.com
<rpihelpme> Ok
<popey> Or ubuntuforums.org
<rpihelpme> is there an arm forum?
<popey> I don't know
<rpihelpme> ok ty for ur time byebye
#ubuntu-arm 2019-07-15
<satellit_> nice:ubuntu mate 18.04.2 with sugar desktop (symantic)
<satellit_> arm
<satellit_> RpiB3+
<satellit_>  /join #fedora
#ubuntu-arm 2019-07-19
<furaidi> Hi there! What I need to know before trying to install subj on old android phone?
