#ubuntu-arm 2009-09-21
<Martyn> what is the Marvell Dove?
<ojn> Martyn: I doubt anyone will be able to tell you. :-) It's an unreleased product.
<Martyn> Z0, Y0, Y1 .. I'm just trying to figure out which flavor is called the Dove
 * Martyn deals with unreleased processors and products all the time.  -laugh-  I'm working with an actual in-hand Cortex A9/quad core chip now.
<Martyn> I love the thing.  Even at 400Mhz it's blazing
<ojn> Ah. Sorry, can't help you there at the moment.
<Martyn> no worries :)
<Martyn> It's just nice to see more flavors making into the karmic builds
<Martyn> dove, pbx-a9, i.mx51, etc.
<ojn> What platform is pbx-a9?
<NCommander> ojn, never heard of it
<NCommander> Martyn, Marvell Dove is Z0/Y0/Y1 ;-)
<ojn> Ah, eval platform for a9
<ojn> "PBX-A9 will be a software and hardware development board for Cortex-A9 MPCore"  http://www.google.com/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fwww.arm.com%2Fpdfs%2FRealView_HW_Platforms_Selector_v10.pdf&ei=NOW3SoOQNZGHlAe825j0Dg&usg=AFQjCNE0OHFAmZK2Y1bD0guaSWHb7mHBug&sig2=FQ-dYezRq72Mg_F8zqR9mA
<NCommander> Martyn, our images only support Y0, and Y1
<Martyn> YOUR images only support it :)
<Martyn> -grins-
<Martyn> I'm well on my way to having a relatively full Cortex-A9 build
<Martyn> once I work out the kinks properly (I still have early boot issues to deal with) I'll start folding them into launchpad
<Martyn> assuming permission
<Martyn> Can you think of any reasons gcc 3.4.6 would _not_ build?
<Martyn> if I just downloaded it and tried doing a make bootstrap?
<Martyn> hmm .. that actually worked pretty well
<armin76> Martyn: dove is marvell's armv7
<armin76> a netbook board i suppose
<ericm_> dove is the codename for the processor
<ericm_> the SoC
<Martyn> arminv7 : I got it zeroed in
<Martyn> once I figured out which marvel chip it was
<Martyn> I don't have that platform yet :(
<Martyn> I have the testchip that ARM made, I have a PBX-a9, and I even have an omap4 now
<Martyn> I /need/ one of the samsung chips, but won't get one until Apple stops eating 'em up
<Martyn> We're still in the 'it's damned hard to get hands on a multicore chip' stage
<Martyn> at least I have three reference platforms now
<Martyn> anyone here a u-boot zen master?
#ubuntu-arm 2009-09-22
<neonfreon> wg 2
<gaspa>  has anyone ever dealt with mmap and virt_to_phys address translation on arm? ogra?
<ogra> whats your prob ?
<gaspa> briefly this: http://linux.omap.com/pipermail/davinci-linux-open-source/2009-September/016102.html
<gaspa> well, not so brief... :P
<gaspa> ogra: I think virt_to_phys behave differently in i386 and arm, but I'm not finding what.
<ogra> i know the minimal addresses are different on arm vs intel ... but that shouldnt stop you from using it
<gaspa> I think so, but I got only zeroes.
<gaspa> did you read the link above?
<lool> gaspa: Hmm isn't the kmalloc area already remapped?
<lool> gaspa: Anyway you want to bring this up on some kernel chan; we're not so much into kernel dev here
<ali1234> gaspa: that sounds exactly like what the android pmem driver does
<gaspa> lool: I tried also calling pfn_range with kmalloc_area directly...(if that's what you meant... otherwise I didn't catch what you said ;) )
<gaspa> ali1234: I don't know at all android, have you any pointer to this pmem driver?
<ali1234> "Android/PMEM: The PMEM (physical memory) driver is used to provide contiguous physical memory regions to userspace libraries that interact with the digital signal processor (DSP) and other hardware that cannot cope with scatter-gather."
<ali1234> source: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/misc/pmem.c;h=44c0ae8515bac186a7a0a3060204b29ef7b21130;hb=f92ea0328d3a0bb5386d52fd68ae4e10ca1ebce6
<gaspa> ali1234: seen, but I'm not facing with device memories, it's just a test to learn using mmap so i'm currently using normal RAM
<gaspa> anyway, i'll take a look. ;)
<ali1234> ok, well, the memory address by pmem is like any other, it just happens to be shared with devices so outside what linux considers general purpose ram
<ali1234> ultimately it just remaps it and makes it into a device file in userspace
<ali1234> it's a bit of a hack to make obfuscated userspace drivers work
<ali1234> there's the /dev/mem driver too which does the same thing but on the whole of the address space
<ali1234> that one is probably simpler/nicer
<gaspa> yes, in fact my code went from that (indirectly)
<gaspa> ali1234: BTW: thanks!
<gaspa> pmem seems interesting, but for other purposes of mine ;)
<ogra> eggonlea, i'm just working on rootstock
<lool> eggonlea: Hey
<ogra> eggonlea, it needs some massive changes to work with the new upstart ... init=/bin/bash doesnt work anymore
<eggonlea> hi
<ogra> well, it does work, but you cant start any services anymore, i'm working since this morning to find a proper way around that
<eggonlea> do you mean the rootfs is created but the /etc/init.d/udev start should be removed
<ogra> the bugfix for teh networking stuff is already in my local branch but doesnt make sense to push unless the rest is fixed
<ogra> new upstart prevents /etc/init.d/xxxx scripts from beiong executed directly
<ogra> you need to use the service utility for that, which only works if upstart is running
<eggonlea> so... will upstart work with "chroot"?
<ogra> but since rootstock uses something similar to init=/bin/bash upstart isnt running and the service utility doesnt find the upstart soocket to send its messages to
<ogra> no, and it doesnt have to
<ogra> it needs to work with a VM
<ogra> and the rootstock installer needs to be spawned by upstart
<ogra> so i'm trying to convert everything to it atm
<eggonlea> I see. so rootstock/qemu should be ok after fixing the init scripts between first_run and second_run
<ogra> well, the second run actually has to become an upstart job
<ogra> and thats what i work on
<eggonlea> please let me know if I could contribute on this.
<ogra> well, do you know much about upstart jobs ?
 * ogra is in the middle of rewriting the installer
<eggonlea> know some high level configuration but no deep understanding into the code
 * ogra fires up another test, cross your fingers ;)
<eggonlea> please
<eggonlea> my pleasure
<ogra> i switched the first stage completely to qemu-arm-static btw ... it takes less than 10min now to get to the VM
<ogra> instead of 30+
<eggonlea> it never costs so much time before.
<eggonlea> I think ~10 minutes for ubuntu-minimum before
<ogra> you mean it doesnt sit eternally in "I: Configuring core packages..." after it switched to VM on your side ?
<ogra> it surely does for everyone else
<ogra> but if the whole thing took 10min for you before it will only take 2 now ;)
<eggonlea> let me see if I could find the log back.
<eggonlea> cool
<eggonlea> I cannot get the log back.
<eggonlea> I'll record them next time
<ogra> after it switched to VM it did a lot of debootstrap processing where it got very slow ... and just sat there
<ogra> i had a lot of user complaints about that
<ogra> i moved all of debootstrap out of the VM and it operates a lot faster now
<eggonlea> I have a question: could we leave the second part to run on the real board intead of qemu?
<ogra> i a later version, not for karmic
<eggonlea> why? any tech obstacle?
<ogra> could you file a whishlist bug about that ?
<ogra> we're past feature freeze
<eggonlea> got it.
<ogra> i wont add new features to it now
<ogra> only fix up existing stuff and add speedups
<eggonlea> Sure, I'll do that.
<eggonlea> so, when do you expect to have a workable one?
<ogra> i hope later today
<eggonlea> what a good news!
<ogra> upstart doesnt seem to be happy to run in a VM though ... i need to find out why first
<eggonlea> thanks and wait... no more question to interrupt your work, then.
<eggonlea> again, if you have anything need a man to test or debug, please let me know.
<ogra> will do, thanks a lot for the offer :)
<eggonlea> or, you could drop your engineering version to me.
<eggonlea> create a branch on LP, send it on ubuntu-arm maillist or to aawlbt@gmail.com directly.
<ogra> http://paste.ubuntu.com/275799/
<ogra> i'm in the middle of reworking it, it wont work, but you can take a look
<eggonlea> got it.
<ogra> note that the new version needs qemu-arm-static installed
 * ogra goes to find some lunch while another test runs
 * eggonlea go home for supper
<gaspa> ali1234, lool: solved... aerhm. I was mmap'ing with PROT_NONE ;)
<ogra> I: ARM rootfs created as /var/build/rootstock-fixing/armel-rootfs-200909221611.tgz
<ogra> I: Cleaning up...
<ogra> .....
<ogra> I: A logfile was saved as /var/build/rootstock-fixing/rootstock-200909221611.log
<ogra> I: done ...
<ogra> WOHOO !
<lool> ogra: WTF is this -Nqemu-arm-static stuff??
<ogra> -N ?
<ogra> no idea, i surely didnt add any -N
<ogra> i guess kirkland added that the statci branch doesnt exist in the other builds, its a second pass with a copy of the sourcetree
<lool> It's ridiculous
<ogra> remove it if it doesnt break the build
<ogra> you cant build -static in the same pass as nonstatic
<lool> ogra: The rules are absolutely horrid
<lool> I've never seen so many policy violations and programming errors in the same rules
<lool> Starting with binary: binary-static binary-indep binary-arch
<lool> Geez clean depends on config.status
<Martyn> Where can I find the launchpad files that generate the karmic-desktop-armel+dove files?
<Martyn> found 'em
<armin76> Martyn: :D
<Martyn> armin76 : generating an image for pbx-a9 is going to be fun
<Martyn> "fun" in the "I think I need a rusty 10 foot stake shoved up ..."
<Martyn> way
<ogra> lool, i refuse any responsibility for clean ! :) but you can blame me for everything with -static
<ogra> sigh, i really wonder how livecd-rootfs still works with the upstart changes
<ogra> cups is definately unhappy about Failed to connect to socket /com/ubuntu/upstart: Connection refused
<lool> What does it changes for livecd-rootfs?
<lool> Hmm probably we should disable start/stop/service there
<ogra> i'm comparing the code atm
<ogra> there is not a single change from Keybuk
<ogra> i wonder why it works
<ogra> oh, it diverts usr/sbin/invoke-rc.d
<lool> Yes
<lool> You dont?
<ogra> nope
<ogra> i run a VM
<ogra> up to now i didnt divert anything ... there was never a need to
<ogra> i dont see it touching start-stop-daemon though
<ogra> (i know it did once in the past)
<lool> I thought you were using a chroot not a vm
<ogra> original rootstock: chroot for first debootstrap stage, VM for rest
<ogra> new rootstock: chroot for complete debootstrap stage, VM for rest
<ogra> future rootstock (if the binfmt issues are fixed): chroot for complete build
<armin76> Martyn: gimme ssh access to the babbage board plz :P
<Martyn> armin76: Sure, give me a couple hours though
<Martyn> armin76: I'm in the middle of doing a new Karmic buildroot on the babbage and on the PBX-a9
<Martyn> armin76: Do you have my IM?
<Martyn> armin76: Babbage v1 is okay?
<armin76> Martyn: armv7 is okay :)
<armin76> how much space?
<ogra> 5x5" :P
<armin76> in fact i wasn't expceting you would say yes
 * armin76 is just happy with ssh+being able to chroot
 * armin76 blames ogra for martyn running away
<ogra> sure sure, blame me !
<ogra> .oO(was martyn -static ?)
<lool> ogra: Why did you name the package qemu-arm-static instead of qemu-static?
<ogra> because its arm onyl
<ogra> *only
<ogra> and needs its own postinst
<lool> But we could easily have multiple binaries in there
<ogra> we shouldnt
<lool> Why not?
<lool> qemu-system-arm is in qemu-kvm-extras
<lool> Among others
<ogra> i personally dont want ppc or mips if i need just an armel chroot
<ogra> yeah, i dont like that either
<lool> You have qemu-system-mips64el and qemu-system-ppc64 and a bunch others with qemu-kvm-extras
<ogra> i'd prefer a binary for every arch
<ogra> but qemu system doesnt need the binfmt stuff
<lool> That would be huge
<ogra> nor does it need the sysctl settings
<lool> 15 binary packages
<ogra> fine
<lool> That's huge
<ogra> i wouldnt mind 15 binary packages if i can then install only for one arch i care for
<lool> The qemu-arm-static approach isn't consistent with qemu-kvm-extras
<ogra> i created it before qemu-kvm was in the archive
<lool> bah it was the same before the qemu-kvm package
<ogra> i just tried to merge the -static stuff into the existing package on kirklands request
<ogra> in any case there exists no -static flavour thats integrated for karmic
<lool> I'm saying it's inconsistent to have one package per target for the static flavour and one package for all targets in the shared flavour
<ogra> apart from arm
<lool> So?
<lool> It's still inconsistent
<ogra> so the naming is fine for the moment
<lool> ogra: What would it change for you if it was named qemu-static?
<lool> Or qemu-kvm-static
<ogra> beyond i highly object having to have ppc sysctl and binfmt mangling installed just because i want arm
<lool> You wont since it only has arm
<ogra> they might even conflict
<ogra> ppc might be added in L
<ogra> i know at least one person trying to work out support for mips and ppc in debian over the next months
<lool> Yeah so your argument that there exists no -static flavour thats integrated for karmic apart from arm is moot  :-)
<ogra> no
<ogra> the package adds binfmt handlers and sysctl settings
<ogra> its different from the non static version
<lool> Yes
<ogra> thats why static binaries should have one package per arch
<ogra> and the proper conflict/breaks settings if needed
<lool> Does debian/binfmt-arm correspond to ARM binaries?
<ogra> yes
<lool> Does it match e.g. ppc binaries
<ogra> no
<lool> So I dont see the issue you mention
<ogra> the magic is different
<ogra> sysctl is the issue
<ogra> binfmt is just ugly
<lool> Isn't there a common sysctl we can find for other arches?
<ogra> i dont want to have a ton binfmt handlers installed if i only need one arch ... as i said before
<lool> I dont want to have 15 packages cluttering Packages.gz
<ogra> if it comes to sysctl there might even be conflicting settings
<ogra> you wont convince me :) if you feel its needed to change the package, do it ...
<ogra> i'll live with it ...
<lool> Ok
<ogra> but you wont convince me :)
<ogra> just tell me how it's called in the end so i can change the arm docs accordingly
<lool> I personally prefer keeping things consistent between static and shared
<lool> If it creates issue we can look into them and see if we need to split
<ogra> its a different purpose
<lool> I think it's premature optimisation to name the package -arm and doesn't match the shared package; I personally find it misleading that qemu-static-arm changes system wide settings in a way not specific to ARM stuff
<lool> Such as the sysctl knob you mention
 * ogra wonders about "udevd[392]: specified group 'fuse' unknown" in the recent rootstock test
<ogra> right, kees and i tried a better approach
<ogra> but the support doesnt work yet
<ogra> so i had to resort to sysctl
<ogra> there are plans for a per binary solution in the security team
<ogra> just not there ydet
<ogra> (see changelog, i went back and forth through several solutions)
<ogra> (guided by kees)
<ogra> hmm, why dont i see the fuse errors in livefs buildlogs ?
<ogra> there is nothing in livecd-rootfs that would touch /etc/group
<ogra> Unpacking linux-headers-2.6.31-101-imx51 (from .../linux-headers-2.6.31-101-imx51_2.6.31-101.8_armel.deb) ...
<ogra> hrm
<ogra> why is that pulled in by ubuntu-desktop
 * ogra sees "apt-get -y --purge remove $HEADERPACKAGES </dev/null || true" in livecd-rootfs
<ogra> oh my
<ogra> so many hacks
<ogra> sigh, rootstock is so time consuming
#ubuntu-arm 2009-09-23
<eggonlea> ogra: new rootstock works here! Thanks!
<eggonlea> after install qemu-arm-static from Karmic (i'm using Jaunty)
<siji> need help
<siji> to compile clutter with SGX support on OMAP
 * NCommander installs bootchart
<ogra> eggonlea, good to hear !
 * ogra did tests until 2am
<ogra> eggonlea, if you find any issues, please file bugs, i'm scared that something regressed
<lool> NCommander: So usplash just works on dove right?
<NCommander> lool, works now. No idea what changed.
<NCommander> lool, probably new kernel or driver updates
 * NCommander is doing the usplash boot charts now
<NCommander> it doesn't look like theres much difference if its enabled or not
<lool> I think there was an issue in initramfs-tools
<NCommander> lool, possibly. no point really dwelling on it unless it re-emerges
<NCommander> lool, ogra http://people.canonical.com/~mcasadevall/bootchart/ - initial bootcharts (for some reason, a bunch of the usplash ones, and one of the no-usplash ones didn't fully write out, and corrupted the tgz). No real difference between having usplash and not having it on dove
<ogra> give it time :)
<ogra> the java conversion tool is very slow
<ogra> erm
<ogra> why doesnt your bootchart stop ?
<ogra> how did you install it ?
<NCommander> ogra, apt-get install bootchart?
<NCommander> ogra, it stops ...
<ogra> way after mine
<ogra> http://people.canonical.com/~ogra/babbage2-karmic-20090916-2.png
<ogra> http://people.canonical.com/~ogra/babbage2-karmic-20090916-3.png
<NCommander> ogra, the conversion tool is very slow on ARM, its fine on my desktop
<NCommander> ogra, I don't get it ....
<ogra> i dont see the S99bootchart-stop initscript in yours at all
<ogra> its java
<NCommander> ogra, I'm not even logging in ...
<ogra> so your xorg comes up after 14sec
<NCommander> ogra, I don't get it, but I usually let the system sit at gdm for awhile, more thatn a minute, so it is stopping
<NCommander> ogra, the framebuffer comes up at the 6-7 second mark
<ogra> it should be up after the first modprobe ran
<NCommander> ogra, oh, it comes up, but it take a bit of time to settle
<ogra> woah, 49MB/s
<ogra> is that SATA ?
<NCommander> ogra, :-)
<ogra> or USB ?
<NCommander> SATA
<ogra> ah
<NCommander> but USB pretty fast on this too
<ogra> well, i get 33 on my slow USB key
<NCommander> lool, ogra, https://bugs.edge.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/435046 - can you hit the nominate button
<ogra> no, but the approve one :P
<NCommander> ogra, er :-)
<ubot4> Launchpad bug 435046 in linux-mvl-dove "Ethernet port on the dove sometimes changes MAC addresses" [Undecided,New]
<lool> NCommander: done
<NCommander> thanks
<lool> NCommander: Give a heads up to bjf on it when you catch him
 * NCommander is on eth30 right now 
<NCommander> Yeah
<NCommander> I think its going up every boot now
<ogra> why do you still use mem=512M ?
<ogra> and console=tty0 ?
<NCommander> ogra, because it doesn't bring up the full memory if you don't :-/
<ogra> is that filed ?
<ogra> i also see no "ro" in your cmdline
<ogra> that should be added
<NCommander> ogra, it was a known issue from Marvell I believe, but I don't think we have a specific bug on it
<lool> NCommander: You might want to attach dmesg to the bug
<ogra> and get it in the right order so quiet and splash sit at the end
<lool> NCommander: Did you try lamont's uinitrd?
<ogra> NCommander, we need to track it
<NCommander> lool, not yet, my TFTP server is broken at the moment, and I just got console access to the dove back about an hour ago
<ogra> tftp ?
<ogra> i thought you made it run from disks
<lool> ogra, NCommander: Please fix the default kernel cmdline now or file a bug about it
<lool> The mem= should be a separate bugs
<ogra> yeah
<NCommander> lool, fixing it now in my branch, once I go over it and make sure its ok, I'll post a comment asking for review
<ogra> NCommander, root=UUID=<$uuid> ro quiet splash
<ogra> thats all you should have ... in this order
<ogra> the ro is important for fsck
<NCommander> ogra, at the risk of a stupid question, does that order actually matter?
 * NCommander is geniunely curious ...
<ogra> its mentioned in docs all across the wiki
<ogra> so it makes sense to keep the same order the rest of ubuntu uses
<lool> NCommander: it does not but let's keep it consistent
<NCommander> right, no problem
<ogra> doesnt matter technically
<NCommander> ogra, good catch on that, changed on my flash-kernel branch. Once I make sure the installer still works with my changes, I'll kick a branch up
<ogra> good
<NCommander> yeah, mem=512M is still needed
 * NCommander files a bug
<ogra> hmm, if i only could find my voltmeter
<ogra> lool, battery bug still presists even after 2 days of charging
<lool> ogra: Reopen it and note that you didn't test the actual voltage
 * NCommander is at eth31
 * ogra wonders when NCommander runs out of numbers :)
<NCommander> ogra, probably eth255
<NCommander> ogra, I already ran out of DHCP leases -_-;
<NCommander> ogra, (that's how I found the magic MAC numbers)
<ogra> set a shorter lease time :)
<NCommander> ogra, I did
<NCommander> udev assigns a new ethXXX number because the MAC address differs I think
<ogra> indeed
 * NCommander filed a bug on this but still this is redicious
<NCommander> (32)
<NCommander> ogra, lool: https://bugs.edge.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/435151 - someone accept the nomination please :-)
<ubot4> Launchpad bug 435151 in linux-mvl-dove "dove kernel requires mem=512M to use all available memory" [High,New]
<lool> NCommander: Do you also see oo.o not starting on dove?
<lool> NCommander: I dont think that needs to be tracked for release
<lool> Ethernet issue is important, mem=512m cleanup is nice to have
<lool> "High" uh
<NCommander> *coughs*
<NCommander> lool, the problem is if you have a board with more that 512MiB (like at Marvell) it won't be able to see it.
<lool> NCommander: now that you learnt how to properly get a bug on the radar you need to learn how not to  :-)
<lool> NCommander: I can see it'sa real life issue which wont hit any of us and will only limit amount of RAM
<lool> Is this blocking the release of karmic?  no
<lool> Is this a nice to have for karmic?  certainly
<lool> Could we decently release an image without that fix?  yes
 * NCommander doesn't remember the last time he didn't file a bug that was High or Critical ...
<NCommander> -_-;
<lool> Critical should really be exceptional
<lool> I might have filed a couple, or perhaps three total
<NCommander> Two or three, dunno the specifics
<NCommander> Its usually one per cycle
<NCommander> OOo starts ...
<NCommander> and then crashs with the InteractiveAugmentedIOException
<NCommander> But I do get the splash screen
<NCommander> ^- lool ogra
<lool> NCommander: that's with latest karmic?
<NCommander> lool, do you want me to start investing time in the OOo bug after the last few dove issues are firmly squashed?
<NCommander> uh
 * NCommander didn't apt-get update today actually
<ogra> well, thats the normal oo.o behavior
<lool> NCommander: You get the same output as in https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009 ?
<ubot4> Launchpad bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,Confirmed]
<NCommander> no
<NCommander> I don't get the first error
<lool> that one javaldx: Could not find a Java Runtime Environment! ?
<NCommander> I only get "terminate called after throwing an instance of 'com::sun::star::ucb::InteractiveAugmentedIOException'"
<lool> NCommander: Ok and it fails to start?
<NCommander> yeah, fails to start
<lool> Then it's the same on non-cortex-a8
<ogra> because you installed bootchart
 * NCommander notes he DOES have java packages installed though
<ogra> it pulls in java
<ogra> by default the oo.o java extensions shouldnt be installed due to CD size constraints
<NCommander> ogra, right. Anyway, I think it might be worth building a rawhide/Fedora chroot, and see if their armel port works w/ OOo
<ogra> i doubt they use our toolchain or compiler version
<ogra> and it works fine with libgcc3_uno.so from jaunty copied in place
<NCommander> right
<NCommander> I knew that
 * NCommander needs coffee
<NCommander> ogra, it seems like the same issue we had w/ thunderbird
<ogra> why do you say that with every second bug ?
<NCommander> ogra, say what? need coffee or?
 * ogra doesnt see any relation between TB and OO.o 
<NCommander> ogra, er, more specifcally, the cause, which was an issue with preprocessor macros, but I'm no expert on this bug
<ogra> TB had build failures
<ogra> OO.o fails to run
<NCommander> ogra, no, it was fail to run mostly
<NCommander> lool, I just had a nasty thought that our dove images might break on whatever hardware Marvell might roll out in the future
<NCommander> even if its Dove compatible
<ogra> suppress such thoughts ?
<NCommander> ogra, :-p
<lool> NCommander: We need to wait until we see more of the future
<lool> NCommander: or perhaps you can check your crystal ball and tell me how Hardware will look like on these devices and how compatible they will be
<lool> NCommander: Remember that the kernel needs to be ported too, adding machine-ids etc.
<NCommander> My magic 8 ball says "Try Again Later"
<NCommander> :-/
<NCommander> lool, hrm ... I completely forgot that the kernel also uses the Hardware field
<NCommander> Ok, feel free to ignore me
<siji> hello all
<siji> i successfully compiled clutter with GLX support
<siji> While trying to compile clutter aplication
<siji> it's giving a error like
<siji> Glib ERROR /build/buildd/glib2.0-2.20.1/glib/gmem.c:136:failed to allocate 1989214296 bytes
<siji> any idea
<lool> NCommander: so you booted lamont's kernel + initrd successfully?
<NCommander> lool, yeah, I got to the (initramfs) prompt
<lool> ogra: is MX51 TO 3.0 a separate file in redboot-imx or is it the same file for to2 and to3 boards?
<lool>    + Add display support on MX51 & MX37 3-stack platforms
<lool> cool
<lool> ah wait that's LCD
<ogra> there is no romram_TO3
<ogra> so i dont see where it would have been added
<ogra> the changelog mentiones it though
<ogra> and yes, no change for our setup wrt displays
<lool> ogra: Hmm I only see -rw-r--r-- root/root    171352 2009-09-23 12:53 ./usr/lib/redboot/imx51-babbage-TO2_redboot.bin
<lool> ogra: Did you confirm that works on babbage 2.0/2.5?
<ogra> thats how we named it, yes
<ogra> with 2.5
<ogra> i dont have a 2.0
<lool> Yeah good enough
<lool> ogra: Perhaps we should add a TO3 symlink
<ogra> i test the imx51-babbage_redboot.bin on 1.0 and imx51-babbage-TO2_redboot.bin on 2.5 usually
<ogra> well, how would we know it actually supports TO3
<ogra> there is no indication in the patch
<lool> ogra: You quoted the release notes
<ogra> i copy pasted the release notes, yes
<lool> Well you say in the ubuntu changelog that it now supports TO3
<ogra> but couldnt find a specific code reference to TO3
<ogra> upstream says that
<lool> hmpf
<ogra> there is nothing specific in the imx51 patch that has TO3 attached to it
<ogra> ogra@osiris:/var/build/redboot_200933/package$ grep TO3 patch-redboot-200933-mx51
<ogra> ogra@osiris:/var/build/redboot_200933/package$
<ogra> and thats the original upstream patch, not the modified dpatch ... (which has CVS dirs stripped)
<ogra> ogra@osiris:/var/build/redboot_200933/package$ grep TO3 patch-redboot-200933-base
<ogra> ogra@osiris:/var/build/redboot_200933/package$
<ogra> same here
<ogra> if TO3 hw works with it, fine ... but nobody added a comment or anything when the code was added
<ogra> i simply trust what they write in their changelog, what else can i do
<lool> ogra: Well either you believe there's TO3 support, then you quote the release notes and assume that what you're building TO3 support, or you dont in which case you dont quote the release notes
<ogra> well, i belive upstream
<ogra> and there is no specific additional TO3 patch or something
<ogra> patch-redboot-200933-mx51.bz2 is the only thing we have for babbage and 3stack imx51
<ogra> and from that i only build the babbage targets
<ogra> i guess the TO2 binary currently has basic support for TO3 and a proper target will be added in a future release, thats how they did it for TO2
<lool> So if the TO2 binary has support for TO3 my proposal stands
<lool> 14:41 < lool> ogra: Perhaps we should add a TO3 symlink
<ogra> ah well, but how would we test TO3 support ?
<ogra> sure i can easily add a link
<lool> ogra: It's in there since you trust upstream  :-)
<ogra> :P
<ogra> ok, i'll add a link :)
 * ogra wonders about 435221
<lool> bug #435221
<ubot4> Launchpad bug 435221 in project-rootstock "rootstock-0.1.2 crashes on missing /dev/pts" [Undecided,New] https://launchpad.net/bugs/435221
<ogra> how can a system be in such a state if deboostrap finished properly
<ogra> (no update-rc.d no udevd)
<lool> Well do you have sysv-rc?
<lool> hmm probably you do
<ogra> its a finished debootstrap (at least it should be)
<ogra> there should be a /dev/pts as well as a udevd and update-rc.d
<ogra> i wonder if the new debootstrap from today causes that
<ogra> i did my tests before it was uploaded
<ogra> but we'll see, i need more info first
<lool>   * ARM: IMX51: Make fec ethernet driver compile
<lool>   * [Config] Disable FEC2 for imx51
<ogra> yeah, just saw that
<ogra> * ARM: IMX51: Fix USB errors ... should make GrueMaster happy
<lool> GrueMaster: ^ check it out
<ogra> once it built
<GrueMaster> yea, I talked to amitk about that yesterday during the sprint.
<ogra> i guess he did already though, since he spnt a day on amits lap to get it fixed
<GrueMaster> Well, we weren't that close.  :P
<GrueMaster> Has anyone else tried SATA?
<ogra> no cable
<GrueMaster> (not sata through usb).
<ogra> well
<ogra> SATA is SATA through USB
<ogra> no matter how you attach it :P
<GrueMaster> on-board sata.
<ogra> is a USB bridge
<GrueMaster> understood, but electrically it is very different than an external HD USB adapter.
<rabeeh> hi
<rabeeh> after 'apt-get upgrade' on karmic i get the following -
<rabeeh> root@dove:~# gconftool
<rabeeh> gconftool: relocation error: /usr/lib/libglib-2.0.so.0: symbol __abort_msg, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
<rabeeh> anyone? ogra? NCommander? lool?
<NCommander> rabeeh, that error sounds vaguely familiar
<rabeeh> looking at the logs; i see the 'apt-get upgrade' failed too with the same reason.
<ogra> weird, i dont get it on imx51
<NCommander> ogra, I know there was something dealing with __abort_msg's as a build failure a month or so back
<rabeeh> i think that the reason might be libglib is being upgraded before libc
 * NCommander notes he usually uses dist-upgrade verus upgrade ...
 * ogra notes that he doiesnt use apt at all since we need to test update-manager :P
<lool> rabeeh: You need to update glib and glibc
<lool> rabeeh: Can you file this against glibc please?
<lool> and sub us
<NCommander> rabeeh, stupid question, are you using one of the official dove images?
<ogra> us being ubuntu-armel :)
 * NCommander sighs
<rabeeh> NCommander: i'm just using karmic from ports.ubuntu.com --> not a live image
<rabeeh> i'm building my own kernel
<NCommander> rabeeh, how'd you install it?
<ogra> well, the live image is an install media ;)
 * NCommander notes we do have official images now, with our u-boot modifications public
<rabeeh> NCommander: can you please send a link?
<NCommander> rabeeh, https://wiki.ubuntu.com/ARM/MarvellDoveKarmicInstall
<NCommander> http://cdimage.ubuntu.com/ports/releases/9.10/alpha-6/
<rabeeh> NCommander: For installing my Karmic, I used debootstrap under a Debian/Lenny chroot, then used that as a base
<rabeeh> NCommander: I haven't used rootstock or other tools
<NCommander> rabeeh, that works, but you don't end up with an Ubuntu ramdisk, or our fancy autostart solution :-)
<rabeeh> :)
<rabeeh> Well, in my mind ramdisk, initrd and other stuff just makes my boot slower :)
<ogra> well, you dont have an ubuntu system then
<ogra> lots of stuff in userspace relies on stuff that was set up in initramfs
<rabeeh> i have a karmic filesystem
<rabeeh> like what?
<ogra> right, you have a filesystem
<NCommander> rabeeh, actually, after leaving u-boot, we hit desktop pretty quickly
<ogra> dm-raid, encrypted dirs, lvm, splashscreen are some i can name off the top of my head
<NCommander> rabeeh, the slowest bit ATM is the physical read from disk (and I'm starting to think its just the ext2 code)
<ogra> beyond that i heard that the new upstart has issues with missing initramfs
<ogra> but thats only rumors :)
<NCommander> ogra, might explain why my SPARC currently panics on startup
<rabeeh> ogra: i noticed that after apt-get update, udev doesn't show up (so i don't have /dev/ttyS0 to open a console on)
<ogra> right
<ogra> make sure to use an initramfs, its not a slowdown in karmic anymore
<NCommander> rabeeh, in general, debootstrap based installs come with a big unsupported label :-/
<ogra> yeah
<NCommander> actually
<ogra> thats why i'm so cautious to promote rootstock to loudly
<NCommander> Pretty much anything short of the alternative or live installer has that label
<ogra> while its noce for unsupported HW its really nothing you should use on imx51 or dove anymore
<ogra> *nice even
<rabeeh> i'll try the dove images.
<rabeeh> NCommander: mechanical drives suffer a lot from seek time on boot. I previously compared boot with SSD vs. 3.5" drive and that was ~50% faster
<rabeeh> (with xfce4)
<NCommander> rabeeh, actually, I think its the filesystem code just being ....
<NCommander> rabeeh, it shouldn't take 10 seconds to load a 3MiB file from a rotary drive, especially if that drive is spinned up
<rabeeh> NCommander: then something is wrong with your drive.
<Martyn> NCommander: Can, if the drive is ATA and neither PIO nor DMA is engaged
<rabeeh> I know for a fact that dove can easily drive HDD full wire speed without issues (~80MB/sec on read with latest 7200rpm drives)
<NCommander> rabeeh, in u-boot?
<NCommander> rabeeh, once the system boots, its fine
<rabeeh> oh
<NCommander> But its the IPL of the kernel and ramdisk that just D-R-A-G-S on
<ogra> SSD is definately a lot faster than rotary
<rabeeh> NCommander: so probably you need to mkfs.ext2 with -b 4096 (4kb block size)
<NCommander> rabeeh, I'll make sure I teach the installer about that when I teach it about u-boot partition types :-/
<ogra> all the 10 second boot targets for karmic+1 rely on SSD
<rabeeh> i recall i had an issue like this; and that seriously boosted the performance
<ogra> you will boot 5 sec slower with rotary
<NCommander> rabeeh, that's good to know. I wouldn't be suprised if u-boot makes some assumptions about partition information that's disappeared on a booted system
<NCommander> rabeeh, anyway, the recommended way to install Ubuntu on dove is to grab the Canonical modified u-boot, grab an alpha 6 image, and play flip the DIPs
<rabeeh> NCommander: it's definetely ext2 code in u-boot since it's running with I-cache enabled, but with D-cache disabled
<NCommander> rabeeh, ow
<NCommander> rabeeh, the only other choice is vfat ...
<NCommander> ow
<NCommander> wb Martyn
<Martyn> thanks
<rabeeh> NCommander: with '-b 4096' block sizes will be 4 times larger, so much less code to run
<Martyn> That's what I get for trying to type on two consoles at once...
<Martyn> I rebooted the wrong machine
<NCommander> rabeeh, *wince*, we have an ext2 /boot partition, thats going to make files larger though
<NCommander> Martyn, have you seen any issues with ext2 speed in u-boot?
<Martyn> No
<NCommander> Martyn, what version of u-boot?
<Martyn> fat16/fat32 and ext2 work fine in my u-boot
<Martyn> tips
<rabeeh> Martyn: how big is your drive?
<NCommander> Martyn, work, and work well are two different things ;-)
<Martyn> I can go back from HEAD and see if there may have been an issue in the past, but at the moment, at least of three days ago, no issues
<NCommander> Martyn, oh, *ahem*
<NCommander> Martyn, our u-boot is 1.3.4 based :-)
<rabeeh> NCommander: all u-boots are the same.
<Martyn> rabeeh : Depends on which test bench machine .. the PBX A9's all have relatively small drives (80Gb)  and the other one has a 1Tb drive, but boots the same
<Martyn> (other one = platform I can't talk about)
<NCommander> rabeeh, I honestly won't be suprised if the ext2 code has been heavily modified in four major versions since 1.3.4
<Martyn> rabeeh : Indeed NCommander is right there .. take a look at the checkins surrounding ext2
<Martyn> NCommander: Are you stuck with the old version for a reason?
<NCommander> rabeeh, at the moment, the lag is tolerable though
<NCommander> Martyn, vendor provided u-boot
 * NCommander hasn't tested load sleep from SSD/ext2 or SATA/vfat to rule out the drive
<rabeeh> Who is Michael Casadevall
<ogra> rabeeh, that guy you talked to the last minutes ;)
<rabeeh> NCommander?
<rabeeh> :)
<ogra> yeah
 * NCommander has been identified
<rabeeh> NCommander: you have lots of warnings on upgrading u-boot on dove board. you seem hurt :)
<Martyn> Beep beep :)
 * Martyn laughs
<NCommander> rabeeh, none of us have JTAG, or a known-working recovery method
<Martyn> warnings?  Something new on the list I should have read?
<NCommander> Martyn, https://wiki.ubuntu.com/ARM/MarvellDoveKarmicInstall
<rabeeh> NCommander: come on; I wrote for you how to configure the bootrom to boot from the rs-232
<Martyn> NCommander: <--- waiting for his Dove board
<Martyn> then again, I'm also waiting on a new A9 based board too .. lots of frigging _waiting_
<NCommander> rabeeh, and we never managed to get it work :-/. That's why we install u-boot to NAND now and have SPI as a backup
<NCommander> (or at least I never did, I dunno if anyone else tried)
<NCommander> er
<NCommander> whoelse
<ogra> NCommander, ? we all have jtags ?
<NCommander> bah
<NCommander> ogra, and no support scripts to debrick with them :-/
<rabeeh> NCommander: i'll try and provide you exact instructions (again) :)
<ogra> no idea
<ogra> but i definately got that little board thats wrapped in a condom and fits into the jtag socket on the dove
<NCommander> rabeeh, well, the problem might be that we don't use windows here
<rabeeh> NCommander: as a cookie, we are considering adding FTDI chip on next Dove board; that will give you USB to serial and USB to JTAG for openocd
 * Martyn goes back to fighting to build more of the userspace full v7
<NCommander> ogra, oh, sure, I got that too, but openbcd doesn't support Dove
<rabeeh> NCommander: minicom works too. it supports kermit
<Martyn> rabeeh : PLEASE do so, if at all possible.
<NCommander> rabeeh, no love here, when encoded to 0x0E, I believe I just get BootROM
<NCommander> *BootROM 1.07>
<rabeeh> NCommander: it will. like openocd didn't support sheevaplug; but now it does
<rabeeh> Martyn: This is on the top of the list
<NCommander> rabeeh, then I can be a little less scary with the dire warnings ;-)
<rabeeh> NCommander: congratualations. you'v got bootrom now :)
<Martyn> rabeeh : Marvel is now diverging from the ARM roadmap though, right?   No dual core A9 based chip, but something different instead?
<NCommander> rabeeh, ENEEDINSTRUCTIONS ;-)
<rabeeh> bootrom is the rom inside the Dove chip.
<NCommander> rabeeh, I gathered that much. There's a distinct lack of documentation on what you can do at that prompt
<ojn> Martyn: Why should Marvel follow ARMs roadmap?
<ojn> they make their own cores
<ojn> +l
<Martyn> I know
<ojn> (since we're not talking comics here :)
<Martyn> Yeah yeah ...
<NCommander> ojn, I'm just waiting for some superhero called THE ARM to come into existence and then make the resulting bad puns
<Martyn> However, I'm curious as to whether a multicore chip is in the works...
<Martyn> (that's v7, rather than v5 based)
<ojn> Something to talk to them under NDA about, most likely.
<NCommander> rabeeh, stupid question, why were you looking for me? (I have my nick on the Dove installation page)
<Martyn> ojn : Well,a s long as rabeeh is on channel .. can't hurt to ask :)
<rabeeh> NCommander: I missed your nick name on the wiki; just saw your name at the bottom of the page
<rabeeh> NCommander: do you use minicom?
<NCommander> rabeeh, I tried it
 * NCommander prefers screen
<ojn> Martyn: not everyone are loose lipped what concerns confidential information. :)
<rabeeh> NCommander: change that to 0x10, instead of 0xe
<Martyn> ojn : Depends on what's confidental ...
<NCommander> rabeeh, I'll check it when I next powercycle the board
<NCommander> rabeeh, I found a pretty decent work around which let me make our modifications to u-boot
<rabeeh> NCommander: ok. when  I used minicom you would see sent 'spaces' from the board. those are xmodem send me some juice commands
<NCommander> rabeeh, actually, you just got an email from me on that subject dated ~2-3 hours ago
<Martyn> ojn : ARM fully published and released the roadmaps, documentation, etc for just about everything on the A9, PBX a9, and partners that are producing chips now .. so I figured Marvell (or it's reps) might now be more open as well.   In fact, there is plenty of information now on the ubuntu wiki regarding the Y0, etc...
<Martyn> ojn : Point being that you never know, until you ask :)
<NCommander> rabeeh, right, I tried to point sx at it. I'll look at that though, since I can remove some of the dire warnings
<rabeeh> I haven't got any email
<NCommander> rabeeh, your rabeeh@marvell.com, right?
<rabeeh> yes
<rabeeh> that's my (spam-me) email
<NCommander> rabeeh, interesting, you should have been Cc'ed on it
<NCommander> check your spam folder from anything from michael.casadevall@canonical.com
<ojn> Martyn: Right, hurting doesn't ask I suppose. :)
<Martyn> ojn : Polish notation revering you are
<rabeeh> NCommander: my junk mail is full on ads on viagras, my friends at Africa that has 100 million $ and doesn't know what to do with; but nothing from Michael
<ojn> Martyn: whatever. :)
<NCommander> rabeeh, woo, disappearing email
<rabeeh> invisible ink email :)
<NCommander> rabeeh, I'll take your invisible ink email, and raise you a 500 mile email
<NCommander> http://www.ibiblio.org/harris/500milemail.html
<Martyn> slowly compiling ubuntu's packages on a PBX-a9 is s-l-o----oooooo---w
<NCommander> Martyn, pedal faster ;-)
<Martyn> NCommander: I need faster A9 hardware, damnit.
<NCommander> Martyn, bah, no you don't
<NCommander> Martyn, I built *KDE* on an NSLU2
<ojn> Just do it on qemu. :)
<Martyn> ojn : I get build fail issues under qemu
<NCommander> rabeeh, see PM
<NCommander> Martyn, system or user emulation?
<Martyn> system
<NCommander> Martyn, odd
<NCommander> Martyn, its stable for ARMv5 for me
<NCommander> Never tried to abuse ARMv7 on it though
<Martyn> NCommander: Which is kind of the point.
<NCommander> Martyn, it could be worse
<Martyn> NCommander: Real hardware is better anyway.  Build -might- finish by friday
<NCommander> Martyn, WTF are you building?
<Martyn> NCommander: Karmic
<NCommander> Martyn, o_o;
<Martyn> a.k.a "everything needed for Karmic server"
<NCommander> Martyn, karmic .... server?
<Martyn> and there are a lot of packages that are completely fubaring because I don't fully grok the launchpad system
<NCommander> Martyn, oh god, don't use Launchpad for archive rebuilds
<NCommander> PLEASE
<NCommander> That's like using a steamroller to open a bag of peanuts
<Martyn> NCommander: You have a better way to rebuild the entire package archive?  If so, I'm all ears
<Martyn> because from what I gleaned from Duncan and company .. I needed the whole launchpad rigamarole
<NCommander> Martyn, rebuildd is one choice for one shot rebuilds. wanna-build/buildd/sbuild from Debian probably work better but require manual intervention on uploads to get them published (unless you tweak buildd)
<Martyn> Well, this isn't just going to be one-shot, hopefully.
<NCommander> lool, ^
<NCommander> lool was working on a spec to do exactly this actually.
<Martyn> Yes, don't know where that got to though
<NCommander> Martyn, do you actually expect to see significant performance increases from ARMv6->armv7?
 * NCommander didn't think ARMv7 added too much to the base instruction set that would improve general application time.
<rabeeh> NCommander: nice :) i'll trade
<Martyn> I'm not doing it for performance.
<Martyn> I'm doing it for power
<Martyn> and to compile with full NEON support for those applications that can use it
<NCommander> rabeeh, I think your spamfilter ate that email
<NCommander> rabeeh, (did you see the private message i sent you?)
<NCommander> as in server side spam filter
<rabeeh> Martyn: is this autovectorization?
<Martyn> rabeeh : Can't comment
<NCommander> Martyn, w.r.t. to public dove documentation, its mostly just a by-product of the Ubuntu development cycle
<NCommander> (i.e., the installation wiki page and such)
<Martyn> *nod*
<Martyn> frankly, I wish a lot of the ARM crap would stop being so cloak-and-dagger
<NCommander> Martyn, the entire process is driven to be open and visible, so the documentation follows the same route.
<Martyn> ARM architecture that is
<armin76> rabeeh: i'm happy with ssh access to dove, gimme :)
<Martyn> so many manufacturers wanting to keep things under wraps, that it slows down innovation and cross-pollination at a time when people's interest in ARM architecture is really starting to explode
<armin76> Martyn: tell me that to me :)
<NCommander> Martyn, I just want OpenFirmware for ARM or equivelent
<Martyn> armin76: Syntax error?
<Martyn> NCommander: UEFI
<Martyn> that's the thing that will eventually be that
<armin76> Martyn: the thing about manufacturers keeping it secret
<armin76> that affects me, because i could do stuff if i had access to the hardware as well
<rabeeh> armin76: you have 78100 and sheevaplug
<rabeeh> marvell is making those announced products public !!!
<armin76> rabeeh: but thats not v7
 * NCommander got to play with a Sheevaplug
<Martyn> armin76 : BTW, I reinstalled the babbage, and am waiting for permission from the CEO to put it in the DMZ so you can ssh into it
<ojn> armin76: there are other armv7 platforms out there. Or do you need to run on a specific implementation to performance tune something? Either way, "do stuff" is barely much of a selling point for hardware access by vendors. :)
<Martyn> ojn : perhaps not, but locking away the hardware from view certainly doesn't help get a robust and vibrant community of developers going either :)
 * NCommander would love to see a vendor successfully see a product that didn't do stuff
<armin76> ojn: i'm eating an icecream, i'll write better answers now
<armin76> after i'm done with it, that is
<Martyn> Best thing ATmel ever did for the mega series of AVR processors, was come out with the inexpensive butterfly dev kit
<NCommander> armin76, what flavor ;-)
<NCommander> Martyn, ooh, I have an old AVR8 board in the closet
<ojn> Martyn: Sure. ARM has some of it going already with the beagle and other cheap platforms
<Martyn> and the best thing TI/ARM ever did, was back the creation of the OMAP3 based Beagleboard
<NCommander> That thing taught me ASM could be fun
 * NCommander was runover by x86 asm as a small child ...
<armin76> NCommander: almond :)
<ojn> armin76: heh
<armin76> ok, i'm done
<armin76> Martyn: thanks :) how much space can i have on it?
 * NCommander goes to hit the installer with a brick
<Martyn> I'm working on an A9 based beagleboard-like implementation, based on the SoC my company is working on
<Martyn> that way there will be the expensive server platform, but also an uber-cheap little board for people to get addicted to
<armin76> ojn: yes, there are other platforms but unlike you canonical guys(are you one of them as well?) i don't have the contacts
<NCommander> Martyn, sounds like the NSLU2
<ogra> armin76, the babbage is really not as exciting as it seems ... the dove with its cool SATA controller is way beyond
<ojn> armin76: no, i dont' work for canonical
<Martyn> armin76: I'll put in one of the 16Gb SDHC cards, should be enough to keep you hapyp
<armin76> ojn: also i don't get paid for doing development on it
<NCommander> Martyn, 16GiB? Bah, I can only find 2-4 GiB around here
<Martyn> ogra : There's a little sata controller on the babbage too :)  It's just not -as- exciting
<armin76> Martyn: it should! thanks :)
<ogra> Martyn, its a fake :P
<NCommander> Martyn, its USB based
<ogra> Martyn, the SATA on the babbage is a SATA to USB bridge
<Martyn> Yeah, I know it's usb based ... but it works anyway
<ogra> it only operates at USB speed
<armin76> ojn: the only manufacturer contact i have is rabeeh, thats why i'm bothering him :)
<Martyn> ogra : True .. that's a bummer
<ojn> armin76: heh
<ogra> i get 60MB/s out of my dove with a 7200rpm disk
<Martyn> ogra : Stop making me jealous
<armin76> ogra: but its still armv7, i'm happy with being able to compile and having nfs
<rabeeh> ogra: is it an old drive?
<ogra> only 16-20 out of the babbage
<ogra> rabeeh, well, what i had lying around
 * NCommander should plug in his UltraSCSI board into his dove then connect a 10,000 RPM drive
<Martyn> ogra : Yeah yeah, but are YOU going to put a dove outside a firewall for armin to play with?
<NCommander> :-)
<ogra> Martyn, no :)
<armin76> ogra: maybe it sucks for you, but if its better than the beagle then its enough for me :)
 * NCommander would if armin76 is willing to access it over IPv6
<NCommander> bahahahah
<Martyn> Well then, the whole idea of which sata implementation is moot then :)
<ogra> its better than the beagle B1 for sure
<armin76> NCommander: i do have ipv6
<ogra> cant compare to the C rev. beagles
<NCommander> armin76, >.<;
<armin76> NCommander: gimme :)
<NCommander> armin76, sadly, my dove's ipv6 address keeps changing
<Martyn> ogra : C rev is the same, but the USB host works, and there is twice the memory
<NCommander> armin76, https://bugs.edge.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/435046 - due to this
<ubot4> Launchpad bug 435046 in linux-mvl-dove "Ethernet port on the dove sometimes changes MAC addresses" [Undecided,New]
 * Martyn again, has to patiently wait for smooth-stone to get a dove to touch one
<NCommander> Martyn, BTW, do you know how many eth devices the kernel can have?
<ogra> right, twice the ram will make some difference
<ogra> 65535 ?
<NCommander> Martyn, I'm trying to figure out if the dove will panic if it hits eth255
<armin76> ojn: also believe me that i've tried to contact freescale and TI about boards, to no avail, so i only have rabeeh :)
<rabeeh> NCommander: just set the 'ethaddr' in u-boot and it won't random your mac address
<ojn> armin76: see /msg
<NCommander> rabeeh, I did
<NCommander> rabeeh, it doesn't work.
<rabeeh> NCommander: saveenv?
<rabeeh> :)
<NCommander> rabeeh, yup
<NCommander> rabeeh, see the bug :-/
<NCommander> rabeeh, its like my MAC is connected to a random number generator
 * NCommander ran out of DHCP leases last night ...
<ogra> get more dhcp servers
<NCommander> ogra, I just moved to IPv6
<ogra> you never see the obvious fix
<NCommander> ;-)
<rabeeh> NCommander: touch /ubuntu/etc/udev/rules.d/75-persistent-net-generator.rules
<lool> ojn: Hey what are you working on?  (in terms of ARM stuff)
 * NCommander blinks
<lool> Martyn: I'm afraid I didn't manage to reserve time to work on my spec so I didn't complete anything remotely useful
<rabeeh> that will keep ethX to eth0; but regardless the MAC address should change after you do saveenv
<ojn> lool: Working at a startup that is currently considering using an arm soc in a product. just doing random stuff
<lool> I only read API docs and played with some scripts
<NCommander> rabeeh, it keeps changing regardless
<ogra> lool, dont say that, rootstock is happily using your kernel hack ;)
<lool> ojn: netbook class, server class, beagleboard like?
<rabeeh> NCommander: can you use the Marvell u-boot
<lool> ogra: True, I did put a shitload of time in qemu in the beginning of the cycle
<NCommander> rabeeh, I can, but I haven't made any code changes that would affect this
<ojn> lool: Sorry, not public information. :)
<NCommander> armin76, 2001:470:1d:8d:250:43ff:fe68:1438
<rabeeh> NCommander: after two boots - http://dpaste.com/97255/
<lool> ojn: armv7?
<NCommander> rabeeh, thats a manually set one, I was just using the default in u-boot
<lool> ojn: it's ok if it's private too  :-)
<ojn> lool: well, most interesting ARM SoC's out there today (and/or soon) are ARMv7.
<lool> Yeah you know I was hoping to bring you on the road to revealing something about your work   :-)
<lool> ojn: You coming to UDS?
<ogra> and if not, whats your excuse :)
<armin76> NCommander: which password? :)
<ojn> lool: hah.   where, when?
<armin76> and user
<NCommander> armin76, wow, you weren't joking when you said you have IPv6
<lool> ojn: mid Nov somewhere in the US
<lool> Final place not decided yet   :-(
<rabeeh> NCommander: that's what i'm saying; you need to set it manually to different MAC
<armin76> NCommander: owned? :)
<ojn> lool: depends on if I can find business justification, I suppose.
<NCommander> armin76, well, I learned my firewalls rules are a bit more permissive than I realized ;-)
<armin76> NCommander: had to set it up to access the mv78100 rabeeh talked about :)
<lool> ojn: It's where we plan for next 6 months of Ubuntu dev
<ojn> lool: right, I know what the event is. :)
<ogra> ojn, you can take influence on behalf of your company ...
<NCommander> armin76, there's something sexy about not popping a hole in the NAT for you
<lool> ojn: I was suggesting that might be good justification   :-)
<ogra> ojn, that should be enough justification :)
<ojn> heh
<ojn> well, locate it in austin and it's an easy decision.
<lool> ojn: But then you cant share much so I cant really give better advice; I cant say we could have a session on netbooks or a session on servers for instance   :-)
<lool> ojn: It might be in dallas
<lool> at which point you can basically walk there
<ogra> ojn, one of the places on the plate is very near
<ojn> lool: that'd be ok
<NCommander> lool, can I pick your mind on a technical question on a how best to implement?
<NCommander> lool, I rewrote flash-kernel so it gets the UUID dynamically by reading /, but I'm not sure how to make this work from flash-kernel-installer, since it will end up calling both f-k-i, and flash-kernel
 * NCommander is kinda thinking of forging a mtab entry in the chroot ...
<NCommander> (https://code.edge.launchpad.net/~mcasadevall/flash-kernel/standalone_boot.scr)
<armin76> Martyn: is the cortex-a9 armv7a or not?
<NCommander> bbiab
<Martyn> armin76 : Yes
<Martyn> lool : Can't wait to have the Ubuntu 6mo here in Austin :)
<Martyn> lool : I finally get to meet all of you in person :)
<Martyn> lool : 3 hour drive to dallas, still would do it :)
<lool> rabeeh: Can you explain how you got the glib warning exactly?
<lool> rabeeh: Cause that should work in karmic, I see a > 2.10 dep on libc on amd64
<rabeeh> apt-get update
<rabeeh> apt-get upgrade
<lool> NCommander: Cant f-k-i just call flash-kernel??
<lool> NCommander: there are examples of UUID computations in flash-kernel already I think
<lool> rabeeh: That's a pure karmic system?
<rabeeh> yes
<lool> libglib2.0-0 Depends: libc6 (>> 2.10), libc6 (<< 2.11), libgcc1 (>= 1:4.4.0), libpcre3 (>= 7.7), libselinux1 (>= 2.0.85)
<rabeeh> root@ubuntu:/tmp# dpkg-query -l | grep libc6
<rabeeh> ii  libc6                             2.10.1-0ubuntu7                       GNU C Library: Shared libraries
<rabeeh> ii  libc6-dev                         2.10.1-0ubuntu7                       GNU C Library: Development Libraries and Hea
<rabeeh> ii  libc6-vfp                         2.10.1-0ubuntu7                       GNU C Library: Shared libraries [VFP version
<lool> rabeeh: odd, that version should be fine
<rabeeh> hmm... shouldn't that build depends on ... ?
<rabeeh> NCommander: where can i download dove live images? and u-boot?
<Martyn> ARGH
<Martyn> build crashed
<Martyn> rabeeh : www.ubuntu.com/testing
<rabeeh> 17-sep is latest ?
<rabeeh> (alpha-6)
<Martyn> yes, but there are some packages that need upgrading after install
<Martyn> there were a lot of changes applied in the last few days
<lool> rabeeh: it does too
#ubuntu-arm 2009-09-24
<NCommander> lool, I'm generating the UUID in flash-kernel
 * NCommander loves reading backscroll hours after the fact
<NCommander> rabeeh, http://cdimage.ubuntu.com/ports/releases/9.10/alpha-6/ - Dove images are here
<armin76> NCommander: ping, can i touch the disk? :)
<ogra> armin76, are you in the US or do you have a long ARM ? :)
<armin76> ogra: i have a dove :D
<armin76> (the animal) :P
<ogra> so you could send it to touch NCommanders disk :)
<NCommander> armin76, sorry, already reinstalled the machine
<armin76> NCommander: np, thanks anyway :)
<NCommander> armin76, how'd your compile tests go?
<NCommander> (I missed the first ping, I had no issue with you tearing up the drive)
<armin76> NCommander: well, i was running out of space, so i just compiled one of the packages i use to check the compile times
<armin76> http://dev.gentoo.org/~armin76/arm/buildtimes.xml <- something like this
<NCommander> armin76, ah, and?
<armin76> NCommander: 50 secs dove 43 secs sheevaplug
<armin76> tmpfs on both
<NCommander> interesting
<NCommander> but the dove was running Xorg, and on the livecd
<NCommander> so a lot less RAM
<armin76> and was also swapping :)
<armin76> NCommander: let me know when you get bored of it :D
<superdug> Greetings!  I am following http://elinux.org/BeagleBoardUbuntu#Development_PC:_Root_File_System and have completed the ./rootstock command ... however I do not have a vmlinuz file
<superdug> I do have the ubuntu-armel...tgz file though
<lool> superdug: Well that's expected
<lool> superdug: It's just meant to create a rootfs
<lool> superdug: If you want a kernel, you have to decide for which board first
<lool> superdug: For beagleboard, there are some prebuilt .deb kernels
<lool> superdug: http://www.rcn-ee.com/deb/kernel/beagle/karmic/ IIRC
#ubuntu-arm 2009-09-25
<puddles> does anybody have a pegatron nettop?  or something based on babbage?
<puddles> (also same as "efika mx")
<siji> good morning all
<eggonlea_> quit
<serdar> hi guys
<ogra> lool, NCommander why is bug 435046 not milestoned ?
<ubot4> Launchpad bug 435046 in linux-mvl-dove "Ethernet port on the dove sometimes changes MAC addresses" [Undecided,New] https://launchpad.net/bugs/435046
<lool> ogra: it is milestoned
<lool> ogra: for 9.10
<ogra> lool, NCommander can one of you please unmilestone the marvell desktop spec ?
<lool> not sure it's worth it ghouth
<lool> ogra: ??
<lool> ogra: Why unmilestone it?
<ogra> its A6 milestoned
<lool> Yeah and was delivered back then
<lool> ogra: Are you seeing my comments on the status report?
<ogra> yes
<ogra> working them in
<NCommander> ogra, its marked as implemented O_o;, why does the milestone need to go away
<ogra> i thought it had to
<ogra> apparently i'm wrong
<ojn> I like how apt-get suggests I install nvidia-libvdpau when installing mplayer on arm. or is it used for tegra too?
#ubuntu-arm 2009-09-27
 * jmc93739653 is away: Away
<lool> ogra: So qemu-arm-static/amd64 seems to work fine except I get a kernel panic on boot when using it to launch the default --no-tarball image
<lool> I don't think it's specific to amd64 and am not sure what's causing this
 * jmc93739653 is away: Away
 * jmc93739653 is back (gone 02:49:35)
#ubuntu-arm 2010-09-27
<bizkut> hi
<devilhorns> ogra, got a minute for a pm ?
<rsalveti> cooloney: hey, after running 40 hours with only one cpu I'm now running it again without l2
<rsalveti> cooloney: 10 hours already, 4 builds, no problem
<rsalveti> without highmem, with 2 cpus and no l2
<bizkut> im running ubuntu on htc desire, chrooted of course xD
<cooloney> rsalveti: without l2, i still met the error
<avinashhm> good morning..
<hrw|gone> morning
<cooloney> 2
<ogra> 3
<bizkut> 4
<hrw> 17
<cooloney> my bad
<ogra> cooloney, no, hrw's ... he broke the scheme
<ogra> :)
<bizkut> i am wrong..is it Fibonacci?i should be 5
<StevenK> 0 1 1 2 3 5 8 13 ...
<bizkut> http://en.wikipedia.org/wiki/File:Fibonacci_spiral_34.svg
<bizkut> reminds me of debian :)
<ogra> apw, yo
<ogra> apw, the omap4 meta package still talks about versatile
<apw> ogra, so it does, hrm wasn't i fixing omap3 last time?
<ogra> yeah
<ogra> sorry i didnt see it until i fixed the linux-header issues on arm
<apw> ogra, ok i've committed the  fix... will make the next upload
<ogra> awesome, thanks :)
<rsalveti> morning
<davidm> G'day all
<ogra> morning davidm
<davidm> hi ogra it's finally fall here :-)
<ogra> heh, here its not really geting day
<ogra> its so grey i have to keep the light on all day
<davidm> ogra, bug #605042 is it in a happy place now?
<ubot2> Launchpad bug 605042 in eglibc (Debian) (and 10 other projects) "[armel] java fails to start with eglibc-2.12-0ubuntu4 (affects: 2) (heat: 14)" [Unknown,Unknown] https://launchpad.net/bugs/605042
<davidm> Or are we still looking to the kernel team for a fix
<ogra> indeed we do
<ogra> i havent heard from Nafallo yet and even if my panda is there as a temporary buildd, we still need the babbages until we can replace the whole set with 2.1 HW
<ogra> so a fix should be developed in any case
<ogra> (also for lucid users, not only for us)
<ndec> lool: ogra: hi! i see that systemtap has been upgraded. thx. one question: it looks like I was made the uploader. is that expected?
<ogra> ndec, you filed the bug :)
<ogra> so yes, that normal
<ndec> ogra: sure. but I did not upload the package... still some launchpad magic that I don't get ;-)
<ogra> you requested the upload :)
<ndec> ogra: it looks like as if I did the changelog for the package.
<ogra> thats right :)
<lool> ndec: it's only from the launchpad perspective that you're seen as the uploader
<lool> ndec: Basically, it recognizes that you prepared the source changes by building, and testing the new source and verifying it works
<ndec> lool: this is right, if I apt-get source, then my name does not show up...
<lool> ndec: Which is normal, since the source was not modified from Debian
<lool> ndec: but the "change" of uploading this source to Ubuntu is your doing
<lool> So you showed up on maverick-changes@l.u.c
<lool> ndec: do you mind if I ask you for some guidance on a kernel bug?
<lool> LP #636522 specifically
<lool> Hmm bug bot seems dead
<ubot2> Launchpad bug 636522 in linux-linaro "arch/arm/mach-omap2/board-omap3evm.c:684: undefined reference to `usb_nop_xceiv_register' (affects: 1) (heat: 8)" [Low,In progress] https://launchpad.net/bugs/636522
<lool> ah thanks ubot2
<ndec> lool: you are trying to enable OMAP4 and OMAP3, right?
<lool> ndec: Eventually, yes
<lool> ndec: I don't think that's needed to trigger the FTBFS in this bug, but I'd like to solve it in a multi-OMAP friendly way
<lool> (I realize the musb driver needs updating for OMAP4 in linux/linux-omap though)
<ndec> lool: yes, this is correct.
<lool> ndec: This seems a bit similar to the syslink approach: it's always loaded on OMAP4, and never loaded on OMAP3, and can either be a module or builtin; I'm just not sure how to chain module initialization properly here though; I also find it fragile to have these deps on xceiv for certain boards in the musb kconfig, and I suspect we could get rid of them
<ndec> lool: i don't know enough about this to help you quickly.
<lool> ndec: I don't think this is any urgent really; I'm using this to learn my way around this stuff a bit better; if you think someone is interested in helping on the topic, that would be awesome, I suspect most people will simply make sure they dont build xceiv as a module and move on to other bugs    ;-)
<seif_> hey guys
<seif_> any1 here interested in helping me try ubuntu on n900
<cwillu_at_work> am I just odd if I don't see /usr/sbin/invoke-rc.d in sysv-rc on arm in lucid?
<cwillu_at_work> the hell;  it sh...
 * cwillu_at_work grumbles at his rootstock
<rlameiro> GrueMaster: remeber my problem with the edirol?
<GrueMaster> Vaguely.
<rlameiro> well, turns out it doesnt work on my laptop either
<rlameiro> it seems there is a lot of changes on the maverick kernel
<GrueMaster> Ah, your usb sound card.  Interesting.
<rlameiro> crimsum told me that
<rlameiro> problems is that i cant track down where is the problem
<rsalveti> rlameiro: hey, saw that your usb issue is still not fixed :-(
<rlameiro> the board is detected
<rlameiro> it just doesnt play
<rsalveti> rlameiro: and probably you'll also face the issue with the stock kernel
<GrueMaster> Very interesting.  I found an old USB sound box that provides RCA/SPDIF IN/Out.  It works fined.
<rlameiro> well, i will need to leave something always on :D
<GrueMaster> Forgot I had it.
 * rsalveti out for lunch, brb
<rlameiro> GrueMaster: yes, its possible, there is a lot of quirks on the usb sound drivers
<rlameiro> and the architechture of the source code changed a lot the last kernel releases
<rlameiro> so, i think, it is maybe a specific issue
<rlameiro> jo-erlend_igep: are you there? jo-erlend
<seif_> so any help here on how i could get ubuntu running on an n900
<seif_> ?
<hrw> there was a project by someone to get 9.10 working on n900
<ian_brasil___> seif_: kubuntu mobile run s on an n900
<seif_> ian_brasil, link?
<ian_brasil> seif_: http://cdimage.ubuntu.com/kubuntu-mobile/ports/releases/
<ian_brasil> seif_: it is a work in progress though
<seif_> ian_brasil, so what do i do
<seif_> i just copy paste it?
<ian_brasil> seif_: huh?
<seif_> how do i install it
<ian_brasil> seif_: right ..so we need to write some docs about how to install
<seif_> ian_brasil, maybe if u guide mwe through i can take notes and write them down
<ian_brasil> seif_:  can you join #kubuntu-mobile
<ian_brasil> ?
<hrw> seif_: shortest guide: grab image, unpack, give n900 proper kernel + args and boot
<seif_> ok got it
<seif_> shit my memory card is 1.86 GB
<seif_> the image when unpacked is 2GB
<seif_> hrw, is it notmal for it to be 2 GB
<seif_> ???
<ogra> it should be even bigger, we dont support images on less than 4G cards
<ogra> it gets automatically grown on first boot
<hrw> seif_: I do not comment on this
<seif_> oh wow
<seif_> ok gonna grab me a 4 GB card
<ogra> what you see if you *woul* unpack it (which you shouldnt) is the filled up space ...
<ogra> free space only exists after it got grown
<ogra> it also will need the initrd thats in the image, if you cant boot with the existing kernel and initrd i'd recommend rootstock instead
<seif_> ok that was just chinese right there :)
<ogra> (these images get only tested on beagleboards, every other subarch of omap3 is a matter of luck)
<ian_brasil> seif_: you need a kernel from maemo
<ogra> ian_brasil, then the image wont work for him
<hrw> ian_brasil: 2.6.35-meego is too good?
<seif_> ogra, if i have a kernal from meego would it work
<seif_> ?
<ogra> no
<ian_brasil> ogra: no..you need to extract the image to the mmc card and use the kernel fro maemo
<seif_> so there is no way to test it on the n900
<ian_brasil> as well as the dsme package from maemo
<ogra> ian_brasil, the initrd contains essential bits without them the image will not work
<ogra> he should use rootstock if he cant use the image kernel
<seif_> ok what is rootstock
<ian_brasil> but the meamo kernel does not have an initrd
<ian_brasil> s/meamo/maemo
<ogra> seif_, see the channel topic ... how to build a rootfs from scratch
<ogra> ian_brasil, worse ... it doesnt have *our* initrd from the image
<hrw> ian_brasil: maemo kernel supports initrd
 * hrw -> out
<GrueMaster> Grrr.  Omap images are bad today.
<GrueMaster> No filesystem.
<GrueMaster> ogra: ^^^
<ogra> GrueMaster, already fixed
<ogra> omap4 is fine though
<GrueMaster> Yes.  I see omap4 is ok.  respin on omap or wait till tomorrow?
<GrueMaster> Who is our dove kernel guy?  Bug 634161 is still not fixed.  3 weeks to turn of parport_pc.
<ubot2> Launchpad bug 634161 in linux-mvl-dove (Ubuntu) "Unable to handle kernel paging request at virtual address 0ce003be - parport_pc driver load issue (affects: 1) (heat: 192)" [High,New] https://launchpad.net/bugs/634161
<ogra> wait til tomorrow
<GrueMaster> ok
<ogra> well, i could fire up a respin as well
<ogra> one sec
<ogra> running
<GrueMaster> I'll keep 1 groggy eye open for it.
<ogra> yeah, no hurry
<ogra> the switch to linaro uboot didnt relly work ...
<ogra> so test if they still boot
<ogra> they are now switched for sure :)
<GrueMaster> Ok
<NCommander> ogra_cmpc: please go join #ubuntu-installer :-)
<GrueMaster> ogra_cmpc: omap failed to build.  Image builder crashed?
<ogra_cmpc> GrueMaster, nope
<ogra_cmpc> race, there is a log
<ogra_cmpc> python-virtkey seems ot have failed to install
<GrueMaster> Doh.
<ogra_ac> wohoo
<GrueMaster> ???
<GrueMaster> I take it you got Ubuntu on your AC100?
<ogra_ac> GrueMaster, well, kind of
<ogra_ac> ubuntu chroot from USB stick with the android kernel
<ogra_ac> but it works
<ogra_ac> and is really snappy
<ogra_ac> sadly android blocks all network access as user :(
<GrueMaster> Now to get our kernel working and get a preinstall image done.
 * ogra_ac wont go *that* far :)
<GrueMaster> Pfft.
<ogra_ac> a real linux kernel would rock though
<ogra_ac> 2.6.29 android isnt really suitable
<ogra_ac> and using ubuntu in a proper way would rock even more (no upstart means you have to fire up everything by hand)
<ogra_ac> and booting without having to use a second laptop would also be helpful :)
<ojn> ogra_ac: nice
<ogra_ac> ojn, well ... hackish but works :)
<ojn> ogra_ac: yeah. It's the easy part. :)
 * ogra_ac wants kernel source
<ojn> ogra_ac: for the android tree or for a mainline-ish kernel?
<ogra_ac> a linux kernel :)
<ojn> ogra_ac: I bet you DON'T want to see the sources for the kernel running on that system right now. The ones coming out of nvidia are _nasty_. The rewrite by the android guys is much better.
<ogra_ac> well, i'd even take an nvidia tree if it would boot
<ojn> ogra_ac: http://android.git.kernel.org/?p=kernel/tegra.git;a=shortlog;h=refs/heads/linux-tegra-2.6.35
<ogra_ac> doesnt work
 * ogra_ac tried that one today
<ojn> What's the firmware on there again? fastboot?
<ogra_ac> there are toshiba patches
<ogra_ac> i cant get the lcd to work for example
<ojn> of course. :) Are they still using 3333 for machine id as well?
<ogra_ac> nor HDMI
<ogra_ac> which is a blind flight without any console
<ojn> Yeah, no serial makes it no fun
<ojn> What kind of panel does it have? similar to what harmony uses? (1024x600)?
<ogra_ac> right
<ogra_ac> 1024x600 but some special thing i guess
<ogra_ac> i tried the different harmony options
<ogra_ac> nothing boots :(
<ojn> I don't think they do any harmony panel setup in the linux-tegra tree at the moment. I've checked in local setup in our tree but I haven't ported it over and submitted it for theirs yet. So you might be better off trying ours and enabling FRAMEBUFFER_CONSOLE:
<ojn> http://git.chromium.org/cgi-bin/gitweb.cgi?p=kernel-next.git;a=shortlog;h=refs/heads/chromeos-2.6.35
<ojn> You'll have to add the 3333 machine id and alias it to harmony
<ojn> of course, chances are they moved around the backlight GPIOs
<ogra_ac> are you working with one of the toshiba devices ?
<ojn> well, backlight, lvds_enable, lcd power, etc, etc. there's 5 or 6 gpios that all have to be set. :(
<ojn> ogra_ac: no
<ogra_ac> or just the devboard
<ojn> I have harmony and a board called seaboard here
<ogra_ac> getting the kbd to work was a challenge :)
<ogra_ac> needs a special ioctl sent to some special device
<ojn> huh
<ojn> If the day had another 6 or 7 hours I'd be happy to tinker with it, but right now there's no spare cycles in my life for it (the 6 or 7 hours would be needed because there are already 5-6 hours claimed by other things :-)
<ogra_ac> well, i would think chromium woud be a good candidate OS for it
<ogra_ac> (i prefer ubuntu indeed, but thats because i use it everywhere else, android really is unusable on it)
<ojn> chromium os? Yeah, maybe. 512MB isn't much fun these days, unfortunately.
<ogra_ac> sufficient for ubuntu-netbook apparently
<ogra_ac> even when run in a chroot :)
<ogra_ac> ojn, http://paste.ubuntu.com/501682/ btw
<ojn> Sure, you can bring it up, but open up 15 browser tabs?
<ogra_ac> let me try
<ojn> ogra_ac: ok a design with custom EC. sucks.
<ojn> ogra_ac: a couple of gmail logins, facebook, youtube, nytimes.com, etc. It'll start to use up available memory pretty quickly
<ogra_ac> sure
<ogra_ac> 5 browser tabs and the whole netbook UI seem to eat 180M according to htop
<ogra_ac> hmm, but firefox lost its snappieness
<ogra_ac> though given its all fbdev its still impressing
<ojn> Didn't that happen years ago? :)
<prpplague> ogra_ac: hey you around?
<ogra_ac> prpplague, sure
<prpplague> ogra_ac: hey question, i need to force xorg to run at a specific bpp, what's the easiest way to do that?
<ogra_ac> phew
<ogra_ac> i'm not up to date on that, with the old gdm you could set it in the config file
<ogra_ac> beyond gdm, i think there is an option
<prpplague> oh and what is the default console user name and password for the ubuntu builds?
<ogra_ac> there is none
<prpplague> hmm
<ogra_ac> it runs oem-config to configure the system and create the user
<prpplague> ahh
<ogra_ac> its all automatic
<rsalveti> prpplague: probably you need to create a x11 config file and set the bpp there by hand
<ogra_ac> :)
<rsalveti> as currently x11 tries to be smart
<rsalveti> and select the "best" option for you
<prpplague> rsalveti: yea, looks like that is what is happening
<prpplague> rsalveti: the "container" is 32bit wide, but its actually just 24bpp
<prpplague> rsalveti: ubuntu seems to be trying to do 32bit
<ogra_ac>  /usr/share/X11/xorg.conf.d/ is the new place for that i think
<robclark> prpplague: w/ xf86-video-fbdev, by default it just uses the default from omapfb
<prpplague> robclark: yea, omapfb is reporting 32bpp
<robclark> if you also have xf86-video-v4l2 installed, then it will change to ARGB for alpha blending with video overlay
<rsalveti> it'll just get the info from the fb and try to use it
<robclark> omapfb reports 32bpp, but r/g/b=8 and a=0
<ogra_ac> thogh /etc/X11/xorg.conf should still be supported
<prpplague> robclark: maybe you need to come by my cube and have a quick look
<robclark> prpplague: ok.. give me a few
 * prpplague what the heck they did for username/password on this build
<ogra_ac> prpplague, the internal build ?
<ogra_ac> i think thats ubuntu/ubuntu (just guessing though, but there was an indian colleague whom i helped debugging where that worked)
<prpplague> neither worked
<ogra_ac> well, rip out the SD and look at /ect/passwd then :)
<ogra_ac> from your netbook
<prpplague> ogra_ac: yea gonna have to do that
<devilhorns> ogra_ac, need 2 seconds of your time for a pm :)
<ogra_ac> devilhorns, shoot
<prpplague> rsalveti: don't support you can give me an example xorg.conf file
<rsalveti> sure, let me check the fbdev options
<ogra_ac> i think it doesnt accept depth options
<ogra_ac> xorg has a -depth option though
<rsalveti> prpplague: http://paste.ubuntu.com/501771/
<rsalveti> maybe something like this
<rsalveti> ogra_ac: yup, -depth and DefaultDepth should work
<ogra_ac> probably worth a try
<rsalveti> there's also DefaultFbBpp if just DefaultDepth doesn't work
<rsalveti> fbdev just has the fb device to use, shadowfb support and rotate
<rsalveti> prpplague: man xorg.conf should give you all the options
<rsalveti> quite good man page, wasn't expecting :-)
 * prpplague has trouble with userspace stuff
<ogra_ac> heh
<prpplague> rsalveti: so put that into /etc/X11/xorg.conf ?
<ogra_ac> yes
<ogra_ac> use the paste from above
<rsalveti> yup, should work
<rsalveti> prpplague: /var/log/Xorg.0.log should tell you if it worked or not
<prpplague> hmm
<prpplague> didn't start x
<ogra_ac> check the log
 * prpplague screams
<prpplague> this ubuntu build is killing me
<ogra_ac> whats the error ?
<prpplague> i can't get user account working
<prpplague> ogra_ac: ok user accounts fixed, whats the easiest way to start up in text only mode?
<robclark> prpplague: add "text" to bootargs
<ogra_ac> add text as option to the kernel cmdline
<prpplague> ahh
<rlameiro> evening ogra, rsalveti, persia et al
<ndec> ogra: you here?
<rlameiro> jo-erlend: evening
<rsalveti> rlameiro: hey
<rlameiro> are you still with video problems?
<ogra_ac> ndec, indeed i am
<ndec> ogra: hey... quite late ;-)
<ndec> ogra: as you know in our PPA we will have gst packages that are based on the ones in main/universe
<ogra_ac> right
<ndec> ogra: the UNE comes with gst core and plugins base, and I need to make sure that when installing omap4-extra they and upgraded or downgraded to match what is in the ppa.
<ndec> ogra: is that going to work for both upgrade (if my version is more recent) or downgrade too?
<ogra_ac> downgrade most likely wont
<ndec> ogra: if i hard code the version in the depends of omap4-extras, will it force the upgrade or downgrade?
<ogra_ac> why didnt you pick a higher version as we discussed before ?
<mpoirier> GrueMaster: do I need a shell script (like panda's) to get sound going on beagle ?
<ndec> well, right now I am using the same version as the one in ubuntu, and I add +tixx at the end.
<ogra_ac> mpoirier, on C4 it should just work
<ogra_ac> XM has issues i heard
<ndec> funny... you heard ;-)
<ogra_ac> ndec, right, that should be fine
<GrueMaster> Maybe.  I just unmute a couple of switches and increase the volume.
<ogra_ac> ndec, haha
<ndec> ogra: what should be fine?
<ogra_ac> to add +tixx at the end
<GrueMaster> brb
<ndec> but then if there is an update in main/updates then I will no longer be more recent...
<ndec> should i use 99.0.10-2ubuntu3+tixx instead?
<ogra_ac> right, you need to update along with that
<GrueMaster> Sorry, phone call.
<mpoirier> GrueMaster: therefore the setting don't work right off the bat - correct ?
<GrueMaster> Yes.  I'm trying to remember the mixer controls (don't have a current image running).  I thought I had it documented in the bug report.
<mpoirier> GrueMaster: the bug report, is it the same as omap4 or a different one ?
<ndec> ogra: so if omap4-extras depends on libgst, and libgst is already installed, as it is with UNE. will it upgrade it from PPA if PPA version is higher? my feeling is that since libgst is already installed it won't be upgraded, unless if I force the version in omap4-extras.
<GrueMaster> Looking, one sec.
<ogra_ac> ndec, you should use >= for that
<GrueMaster> mpoirier: I will need to drop work on dove for a bit to redocument what needs to happen on omap.  Will get back to you in ~10 minutes.
<ogra_ac> gst-blergh (>= 99.0.10-2ubuntu3+tixx)
<mpoirier> GrueMaster: hold on friend.
<mpoirier> All I need you to confirm is that default sound settings don't work - that is all.
<prpplague> robclark: ok i confirmed that the omapfb is setting it to 32bpp
<robclark> prpplague: but x11 is still seeing 16?
<GrueMaster> Yes.  They don't.  But all that needs to happen is a couple of lines need to be unmuted and a couple of volume controls need to be adjusted.  I just can't remember off hand what they are.
<prpplague> robclark: yea
<prpplague> robclark: and i can't seem to figure out where to place that xorg.conf
<GrueMaster> prpplague: xorg.conf should be in /etc/X11
<mpoirier> GrueMaster: it simply highlights that beagle could also use a .conf file under /usr/share/alsa/cards/, like we intend to do for panda.
<prpplague> GrueMaster: thats what i thought, but when i place one there x never starts
<robclark> GrueMaster: fwiw, I think prpplague has a lucid filesystem.. so xorg.conf.d in /usr/lib/X11/xorg.conf.d
<ogra_ac> prpplague, whats the error ?
<ogra_ac> robclark, /etc/X11 still works
<robclark> ahh.. ok
<ogra_ac> xorg merges
<rsalveti> paste us the log, maybe we can check what's wrong with it
<ogra_ac> right
<GrueMaster> mpoirier: I am not sure an alsa.conf file is what is needed.  More like an asound.state.
<GrueMaster> Might work though.  I never delved into the alsa.conf stuff, as I was told a long time ago that it was going to disappear.
<mpoirier> GrueMaster: whatever, I'm just trying to unify the way we setup sound on our platform.
 * prpplague grumbles
<ogra_ac> and asound.state is created on shutdown
<prpplague> looks like my rootfs is corrupted
<mpoirier> GrueMaster: I don't know how tightly alsa.conf and /usr/share/alsa/cards are related.
<mpoirier> GrueMaster: on the other hand I know we'll solve our panda problem with a file under /usr/share/alsa/cards
<mpoirier> I also know that both beagle, beagle XM and gumstix all report the same information under /proc/alsa/cards,
<GrueMaster> It is the format used by  /usr/share/alsa/cards/*.conf
<GrueMaster> The actual alsa.conf file also loads the correct  /usr/share/alsa/cards/*.conf if it exsists.
<mpoirier> GrueMaster: I also know that if we want sound going (without alteration) on our cards, we will need to make differentiation to the information rendered by /proc/alsa/cards.
<mpoirier> GrueMaster: and carve out a .conf file for all our cards.
<ogra_ac> mpoirier, that will be tricky for Xm vs C4
<GrueMaster> Just remember that next cycle we will need to revisit this as alsa is shifting towards UCM.
<GrueMaster> ogra_cmpc: They are the same.
<ogra_ac> there is no easy way to distinguish between them from userspace
<GrueMaster> I have confirmed it.
<ogra_ac> sound wise ?
<mpoirier> ogra_ac: I know.
<GrueMaster> Yes.  They expose the exact same controls, and they require the exact same changes to make sound work.
<ogra_ac> ah, great
<ogra_ac> i thought there was a differende
<ogra_ac> *difference
<mpoirier> ogra_ac: GrueMaster: we are lucky.
<ogra_ac> yeah
<ogra_ac> thanks to TI :)
<mpoirier> ogra_ac: we have to look at alsa UCM seriously.
 * ogra_ac wishes this ac100 would have an OMAP4 
<mpoirier> ogra_ac: I just had a *very* fruitfull chat with "broonie" on alsa-soc.
<rsalveti> ogra_ac: just waits for a panda-based netbook :-)
<mpoirier> ogra_ac: simply put, implementors of the soc sound purposely pushed out any board specific config to user space.
<GrueMaster> Could be worse.  Marvell has changed codecs on their dove boards.  The A0 doesn't even appear to have the HP jack wired.
<GrueMaster> Unless it uses a GPIO to enable.
<mpoirier> ogra_ac: therefore we can't push config for cards to the kernel.
<mpoirier> ogra_ac: implementing something, even if it is well done, would not get accepted upstream.
<GrueMaster> mpoirier: Well, we can for Maverick.  UCM isn't available yet, but will be in Natty.
<mpoirier> GrueMaster: I know, which is why we may have to live with what we currently have.
<mpoirier> a.k.a a .conf file under /usr/share/alsa/cards/
<ogra_ac> grmpf
<mpoirier> GrueMaster: what is the difference between "linux-meta-ti-omap4" and "linux-ti-omap4" ?
<ogra_ac> mpoirier, heh, you should know as a kernel guy :)
<ogra_ac> one is a metapackage
<GrueMaster> The name?  Ask a kernel guy, I just test things.  :P
<ogra_ac> the other the actual kernel
<rlameiro> the meta install the latest available kernel
<rlameiro> its only a selector
<ogra_ac> the metapackage depends on the right abi
<ogra_ac> so you can do updates of the actual kernel without bumping the abi all the time
<mpoirier> GrueMaster: bug 644714, why "meta" ?
<ubot2> Launchpad bug 644714 in linux-meta-ti-omap4 (Ubuntu) "Screen corruption waking from screen blank if no monitor present (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/644714
<NCommander> ogra_ac: I've got a casper patch cooked off, will poke you tomorrow to sponsor
<GrueMaster> Well, as the title implied, I had screen corruption going on, so I was flying blind.  Change the package in the bug (or I can).
<ogra_ac> NCommander, send me a mail so i can get to it forst thing in the morning, not sure when the RC freeze kicks in
<DanaG> How do you even suspend the OMAP?  Last time I tried it with omap3, it didn't work well.
<DanaG> Or at least, had no way to wake it reliably.
<GrueMaster> mpoirier: Also, in answer to your question on the bug report, apport picked that package over linux-ti-omap4.
<mpoirier> GrueMaster: thanks.
<GrueMaster> But I have now updated it.  jfo will probably slap me for it.
<ogra_ac> and he's taller than you !
<GrueMaster> Yea, but I'm fatter.
<GrueMaster> Probably shouldn't have said that out loud.
<gourneau> Howdy Y'all,  I am looking for a cheap, hackable, small (4-7 inch) ARM machine to run Ubuntu, with a host USB port.  The best I have found is a SmartQ v3 (http://j.mp/9t0tYk). Anyone know of anything better?
<GrueMaster> Beagle/BeagleXM?
<mpoirier> rsalveti: ogra_ac: did you receive a patch from either berco or Igr concerning bug 637947 ?
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/637947
<gourneau> Oh sorry, also it needs to be battery powered.
<rsalveti> mpoirier: not directly, just the patches that are attached already
<GrueMaster> gourneau: http://www.alfonsomartone.itb.it/qcblft.html
<GrueMaster> http://www.liquidware.com/shop/show/BB-BJC/BeagleJuice
<GrueMaster> http://www.liquidware.com/shop/show/BB-ULT/Ultimate+Beagle+Gadget+Pack
<GrueMaster> Lots of ideas.  The base system is hella-cheap and low power.
<gourneau> Thanks for those links, the tablet pack looks very close to what I want.
#ubuntu-arm 2010-09-28
<rlameiro> rsalveti: I was trying to follow the advice that someon gave in the bug about usb, but https://wiki.ubuntu.com/Kernel/MainlineBuilds
<rlameiro> here they say its only i386 and AMD64
<rlameiro> jo-erlend: are you there?
<persia> ndec, ogra: If a special version of gstreamer is required, in a version-independent way, give it a slightly different name, with Conflicts/Replaces/Provides.  This will break external versioned dependencies, but will ensure the requested version is always installed.
<ogra_ac> hmm
<rsalveti> rlameiro: I'd say this bug is probably not fixed upstream
<rsalveti> currently the best supported kernel for igepv2 is the stock one
<NCommander> GrueMaster: do we have bug numbers for the missing ubiquity icon and oem-config?
<NCommander> (on dove?)
 * NCommander has a mostly viable patch ready to roll
<GrueMaster> Ok, found it.  Bug 643791.
<ubot2> Launchpad bug 643791 in ubiquity (Ubuntu) "Installation icon missing from Dove live image. (affects: 1) (heat: 531)" [High,Triaged] https://launchpad.net/bugs/643791
<GrueMaster> Google is my hero.
<DanaG> Ultimate beagle gadget pack.... great, now how do you use the LCD?  Last time I'd heard, there wasn't generic kernel support for it.
<DanaG> And there's also no generic battery support.
<persia> Is there non-generic support?  What needs to be generalised?
<DanaG> Beats me -- I don't have a battery to try.  A friend of mine tried to get an LCD working, and it was non-trivial -- required modifying kernel source files.
<persia> That's relatively easy then, as it only needs be done once.
<DanaG> And the beaglejuice thing doesn't seem to provide any way of monitoring (such as I2C or SPI).
<persia> No monitoring is a bit more annoying.
<DanaG> And the modifications to kernel would be different for each LCD.  Some have different timings.
<DanaG> For example, 480x272 wasn't doable with stock mode db.
<persia> I'm not fussed about needing to add to the stock mode db.  Breaking everything else would be bad, but that just means we have a target for generalisation.
<DanaG> Heck, it'd even be reasonable (maybe) to add some modeline-like syntax for the kernel parameters.
<persia> I'd much prefer having something that worked for autodetect.  Anything that requires passing kernel parameters seems like a workaround to me.
<DanaG> yeah, autodetect would be awesome.
<persia> Oughtn't be that hard, really.
<persia> The main issue is ensuring that each bit of hardware either has a unique detection signature *OR* there exists some protocal (e.g. EDID) by which parameters can be requested.
<persia> I'd guess 75% or so is just janitorial work on the code: avoiding cases where some family of controller chips ends up being hardcoded to always be a 382x160 LCD unless overridden, etc.
<DanaG> I'm not sure the LCD-controller pins even have a way to do EDID.
<persia> I don't think they do.
<persia> I think we'd need a large sample set of returns from devices to build a detection routine.
<persia> We can fairly reliably identify a controller chip, so the first stage is probably differentiating chips in the same family.  The next would be, for each chip, identifying responses to various probes: most ought implement some out-of-bounds checker, meaning that we ought be able to identify the size through that, and some bit depth error code if we go too deep.
<persia> Then this needs to be reported to userspace in some useful manner.
<DanaG> I see... LCD header DOES have i2c3_sda line.
<DanaG> But only SDA.
<DanaG> iSN'T there also supposed to be a clock?
<persia> There's always a clock, but it's not always exposed as a clock.
<hrw> morning
<Baybal> evening
<berco> persia: ping
<persia> berco, Good day.
<berco> persia: hello
<berco> persia: one question for you. Do you know how asound.state is generated?
<berco> persia: it seems this file overwrites our settings
<persia> How are the settings being set?
<berco> we finally have an /usr/share/alsa/cards/SDP4430.conf file
<berco> this file is being read now with our changes in the kernel
<berco> But even if we suppress the asound.state file in /var/... it still gets regenerated but with different values than in our SDP4430.conf file
<berco> then amixer cget command reports the values from asound.state
<lool> Hmm is there a need for two x-loader source packages?
<persia> berco, Sorry for the delay (I'm also in a meeting).  It looks like it's a call into /sbin/alsa-utils that does it.
<persia> berco, Look at the restore_levels() and preinit_levels_on_card() functions
<persia> It's intended to save current state and then restore, but obviously something is going wrong.
<berco> persia: also what I found out
<berco> do you htink we need a udev rule?
<persia> I'm not sure how that will help in this case.
<persia> echo_card_indices() ought be sufficient to detangle load order issues.
<berco> persia: I will investigate. Going to lunch now :-)
<persia> Enjoy.
<rlameiro> rsalveti: jo-erlend there is now an IRC channel for igep, #igep
<lool> Hey rlameiro
<rlameiro> lool: hey :D
<lool> rlameiro: It's great to see you on IRC; I've been looking for an #igep when I got the board!  :)
<avinashhm> hi, if anyone uses ddebug , does dynamic debug [ddebug] support multiple files ..???
<rsalveti> gm
<vstehle> Hi ogra, did you try the OMAP4 preinstalled image recently? I think I have instabilities on two different boards with today's image...
<ogra> oh ?
<ogra> i didnt try since last week
<ogra> though you should wait for the RC buiold later today or tomorrow
<vstehle> ogra: What I did was simply to install the image, let it resize, go through the installer and let it sit idle for some minutes.
<ogra> there were 100s of bugfixes the last few days
<rsalveti> vstehle: what errors did you get?
<ogra> yeah, what did you see
<rsalveti> yup, true
<vstehle> rsalveti: I get freezes, that's what I get :) I thinks it is linked to activity on the USB keyboard... No more heartbeat led. Dead.
<ogra> sounds like kernel
<rsalveti> hm, yeah
<vstehle> rsalveti, ogra: I'll wait for the rc and re-test. No hurry.
<rsalveti> vstehle: do you have console?
<rsalveti> maybe we got a trace
<vstehle> rsalveti: No. I think that at some point, when I typed on UART it had an effect too!
<vstehle> rsalveti: No trace, sorry. I can retry if you are interested.
<rsalveti> that'd be good, but let's wait rc, probably better
<vstehle> rsalveti: I have only the 6 layers board right now.
<rsalveti> then we can test a better image
<ogra> oh, i dont have my 6 layer anymore
<vstehle> rsalveti: I retry with console on that one. But only once :)
<rsalveti> vstehle: weird, the only 2 issues I got currently on 6 and 8 are the highmem and display issues
<rsalveti> but no hang
 * ogra too only sees the display issues
<vstehle> I'll capture some traces and come back.
<rsalveti> vstehle: cool :-)
<rsalveti> and it turns out that the led is actually usefull :-)
<rsalveti> annoying, but useful
<ogra> its not that annoying if the board sits idle :)
<rsalveti> yeah, true
 * rsalveti out for lunch
<GrueMaster> My system has been up now for almost 20 hours.  No hangs to report.
<GrueMaster> This is the 20100927 image.
<ogra> that's so yesterdayish
<ogra> but good to hear :)
<GrueMaster> Well, there is no image yet for today (that I have seen).
<GrueMaster> And it is updated.
<ogra> i wasnt serious :)
<mpoirier> ogra: I just touched base with Tim on the 6 patches submitted by Enric Balletbo.
<ogra> what did he say ?
<mpoirier> ogra: there is next to no chance of getting them in before the release.
<mpoirier> I will write SRUs for them and they will go in after.
<ogra> i didnt expect them before release
<ogra> cool !
<mpoirier> me neither.
<mpoirier> also,
<mpoirier> in the TI meeting last week, you mentionned that when you hit the display problem,
<mpoirier> to change the console..
<mpoirier> what does that mean exactly ?
<ogra> pressing ctrl-alt+f1 --- then ctrl-alt+f7
<mpoirier> and what does that do for a living ?
<ogra> it switches ttys
<ogra> and if i return to tty7 my screen is back
<mpoirier> humm...
<mpoirier> never done this before, let me try...
<mpoirier> ogra: I'm faced with a weird display problem on my panda.
<mpoirier> the screen goes blank after a while and doesn't come back.
<ogra> how does that manifest ?
<ogra> yeah, thats the one
<mpoirier> no error on the screen, unblanking won't work, nor the above little trick.
<mpoirier> serial console is responsive...
<ogra> ouch
<mpoirier> I've hit something like that before... I think.
 * ogra hanst seen that
<mpoirier> I won't do anything about it just now.
<GrueMaster> I think you are referring to bug 644714.
<ubot2> Launchpad bug 644714 in linux-ti-omap4 (Ubuntu) "Screen corruption waking from screen blank if no monitor present (affects: 1) (heat: 526)" [Undecided,New] https://launchpad.net/bugs/644714
<mpoirier> maybe...
<mpoirier> just maybe.
<GrueMaster> I think what is happening is the system is querying for edid each time.  I hit it the most with my hdmi switch box.
<GrueMaster> Very reproducable.
<mpoirier> I was looking at that bug too.
<mpoirier> GrueMaster: I'll get back to you when I start investigating this bug.
 * GrueMaster isn't going anywhere soon.
<mpoirier> GrueMaster: I think just reproduced the proble you've described.
<mpoirier> fixing it will be fun.
<GrueMaster> Well, enjoy yourself.  :P
<mpoirier> A potential solution will be to keep the highest resolution the system has seen so far and set it to that when EDID can't be read.
<mpoirier> or maybe it this is how upstream has designed the thing...
<mpoirier> if no EDID, set to lower possible resolution.
<GrueMaster> That I think is the proper solution.  Not sure what other systems do, you might check dove & babbage solutions.
<GrueMaster> I know it goes to 640x480, which I don't think it properly supports.
<mpoirier> I don't have dove nor babbage so I can't test.
<GrueMaster> You have source trees.
<GrueMaster> And I have hardware.
<mpoirier> Yes, but trying will be easier and much more reliable.
<thalass> good evening
<mpoirier> like finding needle in hay stack.
<mpoirier> good evening.
<GrueMaster> What I am implying is that these platforms have no kernel parameters (unlike beagle), yet they maintain their resolution settings.
<mpoirier> GrueMaster: have you done the same test on those platform ?
<GrueMaster> They are all on the same switch/monitor.
<GrueMaster> And it is a 19" widescreen 1440x900.
<mpoirier> and you see the problem on omap4 only ?
<thalass> I'm curious about the ARM version of Ubuntu, and whether anyone has tried it on a Nokia N900. I'm getting one soon, and if Maemo support fades away after a while i might decide to go with ubuntu rather than this meego thing nokia are replacing maemo with.
<GrueMaster> yes
<GrueMaster> Now, babbage is set to 1024x768 it appears.
<mpoirier> GrueMaster: how about omap3 - what is the behavior ?
<GrueMaster> Omap3 has a kernel parameter at boot for video.
<GrueMaster> omapfb.mode=dvi:1280x720MR-16@60
<GrueMaster> So it should stay at a fixed resolution.
<mpoirier> it *should*, but does it stay at a fixed resolution ?
<GrueMaster> babbage may be hardcoded to run at 1024x768.  Not sure.
<GrueMaster> Haven't seen an issue with beagle changing resolution.
<mpoirier> had there been one, would you have hit it ? i.e has a beagle ever been in teh same setup ?
<GrueMaster> Only recently have I added the panda to the hdmi switch.  I bought the switch specifically so I wouldn't have to buy more monitors.
<GrueMaster> Beagle, XM, and babbage have shared this configuration all cycle.
<mpoirier> has beagle ever been connected to the hdmi switch ?
<mpoirier> ok.
<mpoirier> it will be interesting to see if the resolution on omap4 stay the same if using "omapfb.mode=dvi:1280x720MR-16@60"  in u-boot...
<GrueMaster> Well, one way to find out.  Give me a  few minutes.
<mpoirier> cool.
<ynezz> how do you set the resolution if not in u-boot?
<ynezz> as I understand it, fb_ddc is not working on omap yet, so the kernel will fallback to some default
<mpoirier> ynezz: to the best of my knowledge, in omap3 u-boot is the only place.
<mpoirier> ynezz: on omap4, the driver parses the EDID and set resolution to highest possible.
<ynezz> wow
<GrueMaster> thalass: Do a google search.  From what I understand, there is documentation available on how to do that.
<ynezz> mpoirier: it's the tree with this EDID parsing for omap4 available somewhere?
<mpoirier> ours does it.
<mpoirier> ynezz: sorry, ubuntu doesn it.
<mpoirier> ynezz: sorry again, ubuntu DOES parse EDID.
<ynezz> :)
<ynezz> in kernel?
<mpoirier> yes.
<ynezz> gotta find it
<mpoirier> find what, the ubuntu kernel ?
<ynezz> yes, the source for omap4 kernel and look how it's done and possibly backport it to omap3/beagle
<mpoirier> rsalveti: you on ?
<mpoirier> ynezz: hold on.
<ynezz> I've started some work with EDID parsing in u-boot already, but than have been told, that it would be better to have it proper place, in kernel
<mpoirier> ynezz: that is the same conclusion ubuntu came with.
<mpoirier> ogra: my buggy brain remembers rsalveti was doing something with EDID in omap3.  Do you recall ?
<GrueMaster> bjf: You sent out a test request for lucid proposed kernel updates, but I am not seeing one for fsl-imx51.  Could you check to make sure it built and was published?
<mpoirier> ynezz: ok, it's just you and me here.
<mpoirier> ynezz: I was supposed to backport omap4 for EDID feature to omap3.
<mpoirier> but, to the *best* of my recollection, rsalveti had started the work.
<ogra> mpoirier, yes, but it didnt make it in
<mpoirier> ogra: what do you mean ? technical problem or time constraints ?
<ogra> time
<bjf> GrueMaster, https://edge.launchpad.net/ubuntu/+source/linux-fsl-imx51
<ogra> he took over from dyfet
<bjf> GrueMaster, 2.6.31-608.20 went into proposed 3 hours ago
<mpoirier> ogra: I'm talking about backporting omap4 EDID functionality to omap3
<GrueMaster> Yea, well system isn't seeing it yet.
<ogra> mpoirier, wes, he had two ideas, one was to just hack it into u-boot and the other was to do it properly in the kernel
<ynezz> mpoirier: cool, found that [PATCH 0/2]OMAP:DSS:RFC for HDMI in OMAP4
<ogra> mpoirier, buit there was time for neither
<mpoirier> ogra: he should have told me... I can probably do something about it.
<rsalveti> mpoirier: I'm now
<mpoirier> rsalveti in the flesh - cool !
<mpoirier> rsalveti: what's the status on backporting omap4 EDID thing to omap 3 ?
<rsalveti> mpoirier: backporting is not actually the right thing right now
<rsalveti> we should improve it first, try to use the common kernel api for edid
<GrueMaster> bjf: Source is visible at http://ports.ubuntu.com/pool/main/l/linux-fsl-imx51/ but no .deb
<rsalveti> and then propose a common solution
<rsalveti> what I got is a patch that parse the edid and try to set up the default resolution for omap 3
<rsalveti> the draft works, but will need improvements to send it upstream, and the omap 4 driver needs a lot more love
<rsalveti> mpoirier: this bug is not related with edid I'd say
<mpoirier> rsalveti: what bug ?
<rsalveti> it's probably the bug I'm facing with my monitor, that I was planning to start debugging it today
<rsalveti> the 640x480 on omap 4
<ynezz> rsalveti: can you pls share your patch?
<mpoirier> rsalveti: ynezz was asking about the backport of Rob Clark's work on the omap4 EDID.
<rsalveti> ynezz: sure, will publish it at my tree and send you the link
<ynezz> this is my beginning with EDID parsing in u-boot http://github.com/ynezz/u-boot-sakoman/commit/36ab7487e1b55ae54b44b02196c4ebfd8ebe1a58
<mpoirier> that's when I told him about your work, hence this discussion.
<GrueMaster> bjf: Nevermind.  Looks like it just started building.
<ynezz> but I'll rework it to use the EDID parsing code in kernel
<rsalveti> ynezz: yup, saw that, also did something similar when trying the edid parsing
<rsalveti> ynezz: cool, nice to see more people interested on that
<bjf> GrueMaster, sorry was a little premature there
<GrueMaster> bjf: Heh.  No big deal.  I was just making sure it wasn't stuck in post-build limbo which has happened in the past.
<rsalveti> ynezz: just give me some minutes and I'll publish it, cause I'm waiting a kernel built to finish on the same tree
<ynezz> rsalveti: no problem, I don't need it today or tommorow :)
<rsalveti> ynezz: what's your email? will send you explaning what I did and what is the state of the omap 4 implementation
<ynezz> ynezz@true.cz
<ynezz> but maybe it would be better to follow up on my email in beagleboard mailing list
<ynezz> there are others interested in this
<ynezz> thanks
<rsalveti> sure, np
<mpoirier> GrueMaster: how's your testing going ?
<GrueMaster> System is in the middle of a package update.  Should be able to try testing in 10 minutes or so.
<ynezz> rsalveti: I wonder if the omap4 patch makes it in, looks to me, it's duplicating a lot of code already available in fb_dcc
<rsalveti> ynezz: yup, that's why it needs more work on it first
<rsalveti> it's parsing it by hand
<rsalveti> I tried to use it on my patch the most I could
<rsalveti> so we'd avoid having duplicates
<GrueMaster> Hmmm.  This is interesting.  While watching apt-get install packages, it will fill the screen with gdk-pixbuf errors (which I will need to file a bug on) and then it starts typing the last line 1 character at a time for about 20 characters before resuming full speed.
<GrueMaster> The gdk-pixbuf issue appears to just be a flood of warnings.
<mpoirier> persia: you on ?
<GrueMaster> It is 1:35am his time.  Doubtful.
<mpoirier> GrueMaster: he told me to poke him at any hours of the day...
<mpoirier> I'm trying my luck...
<mpoirier> GrueMaster: you panda,
<mpoirier> do you boot it with DHCP or static IP ?
<GrueMaster> Hey, lets not get personal.
<ynezz> rsalveti: ok, I've found the thread on linux-omap mailing list about that EDID/HDMI/OMAP4 and I'll ask that guy some questions about OMAP3 support, as I see it would be wise to have some common functionality for both cores from start
<GrueMaster> Oh.  DHCP.
<rsalveti> ynezz: do you have the link or thread name?
<mpoirier> ok. does it keep the same mac address after every boot ?
<ynezz> rsalveti: http://www.spinics.net/lists/linux-omap/msg35867.html
<GrueMaster> I'm not sure.  Have to check the logs.
<rsalveti> ynezz: oh, about the hdmi, thanks
<mpoirier> doing ifconfig -a will tell you.
<rsalveti> ynezz: you can ask mythripk directly :-)
<GrueMaster> Not very well.  I do image testing.  Meaning I have a new image almost daily.
<mpoirier> also, if the mac changes, you *should* get a different ip address.
<GrueMaster> I can more easily check my dhcp logs.
<GrueMaster> one sec (requires monitor switch).
<mpoirier> as you please.
<rsalveti> ynezz: but I believe one thing is the hdmi driver, another is the edid parsing
<rsalveti> for the only the edid parsing part could be common for both omap 3 and omap 4
<ynezz> brb
<GrueMaster> mpoirier: Doesn't look like it, but then again, I'm not sure.  I only have one entry in my server for panda8 (8 layer ES2.0), but 3 different mac entries for panda6 (6 layer ES2.0)
<mpoirier> GrueMaster: are you doing anythign special with your panda8 right now ?
<thalass> Gruemaster: Thanks. I didn't find much before i came in here, but it does seem promising. I doubt i'll attempt it while the phone is under warranty. But thanks!
<GrueMaster> mpoirier: Not really.  I was mainly focusing on dove audio today while I await RC images.
<mpoirier> is your panda8 up ?
<GrueMaster> Not at the moment.  Ran out of spare power supplies (have to timeshare with my XM at the moment).
<GrueMaster> I plan on getting another one today.
<mpoirier> GrueMaster: ok, when you do bring it up, please do an ifconfig from the console and note the mac address.
<mpoirier> from there reboot, and check the mac again.
<mpoirier> mine changes from boot to boot.
<ynezz> rsalveti: I don't know much about omap4 and its differences between omap3
<mpoirier> GrueMaster: either driver issue or not MAC has been programmed in eeprom.
<ynezz> rsalveti: as I understand it, on omap3 you can read edid using i2c3 and on omap4 using hdmi, right?
<rsalveti> ynezz: http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.0_Public_TRM_vJ.pdf in case you want to know more about it
<rsalveti> ynezz: right
<ynezz> rsalveti: ok, so I think, that the right place to do that stuff would be using fb_ddc, just adding something like drivers/video/omap2/i2c.c for omap3 and drivers/video/omap4/hdmi.c for omap4 with code which will contain same functionality like for example drivers/video/nvidia/nv_i2c.c
<ynezz> code for just reading edid and leave the rest on fb_ddc
<rsalveti> ynezz: yeah, that's what I think
<rsalveti> give me just a min and I'll show you what I did
<ynezz> cool
<GrueMaster> mpoirier: Yes, it appears to change.  Not sure if that can be "fixed" by setting a variable in the boot.scr.  I don't think this version of uboot supports the nic.
<mpoirier> GrueMaster: thanks - it confirms my suspicion.
<mpoirier> I'll check with TI before opening a bug...
<GrueMaster> You may not get very far.  Dove has the same issue and there has been a bug on that for two cycles.
<GrueMaster> Their answer was that they didn't want to cause conflict between two systems with the same mac.
<rsalveti> ynezz: please check http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/omap3-edid-parsing
<rsalveti> ynezz: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=commitdiff;h=a0ea712b64988ccd7984069b99864a1b4ac43881;hp=99372b26f533da4d9f6e59a744c67170a7d990d3
<rsalveti> here you can find how I'm probing and parsing it
<ynezz> ok, thanks!
<rsalveti> I decided to first generate the modedb, like any other video driver we have, and then try to get the best one
<rsalveti> it's dvi, but I'm only using CVT with reduced blanking
<rsalveti> to get better timings
<rsalveti> ynezz: and then the dpi_check_timings will try to adjust the timings to be ok with the pck
<rsalveti> so if you have an example that has a higher pck (limit 86500), it'll try to adjust the vsync and hsync
<rsalveti> so it can work at least from the omap perspective
<rsalveti> but then you need to check if this is actually supported by the monitor, otherwise you'll easily get out of sync
<rsalveti> ynezz: if you activate debug at drivers/video/fbmon.c you'll see all the modes and everything, quite cool
<rsalveti> ynezz: I know the panel-generic is not the right place, was using it just to get a working model
<ynezz> and another one from tomba http://groups.google.com/group/beagleboard/msg/bd988bdaa65b7d58
<ynezz> :)
<rsalveti> yup, a little bit similar, but he register an i2c device
<rsalveti> with my patch I get Best Mode: 1280x1024@56 from my monitor
<rsalveti> it's the same one you'll get when using 1280x1024MR@60
<ynezz> cool, will try it on my TV :)
<rsalveti> ynezz: but I also want to improve it to get the best one respecting the aspect ratio
<rsalveti> 1280x720 looks better at my monitor
<ajay> hi i all i am not able to get uboot prompt over minicom
<ynezz> rsalveti: I've stolen a few EDID dumps somewhere http://github.com/ynezz/u-boot-edid/tree/master/test/
<ynezz> rsalveti: parsing them and looking into the output seems quite interesting
<rsalveti> ynezz: hm, lots of interesting ones, cool :-)
<rsalveti> ynezz: do you have all these monitors to test? would be awesome
<ynezz> nope :)
<ynezz> jsut this one http://github.com/ynezz/u-boot-edid/blob/master/test/edid.lcd.tv.samsung32inch
<rsalveti> got it :-)
<rsalveti> that's the main reason I postponed this feature for maverick, lack of monitors to test at the moment
<rsalveti> wanted first to be sure that we're not getting a bizarre result with some monitors
<GrueMaster> ajay: What system are you using?  Do you have your serial port set to 115200?  Null Modem Cable?
<ynezz> rsalveti: we've quite a few different 14-27", different vendors in the company, so I can test it, no problem
<rsalveti> cool, good to know
<mpoirier> GrueMaster: did you have time to dig up the few options needed to get beagle sound going ?   No big deal if you haven't...
<GrueMaster> No, but I can in a second.  System is available & idle.
<mpoirier> cool
<GrueMaster> sorry, network is running a bit slow.  Mirror must be updating.
<GrueMaster> mpoirier: http://paste.ubuntu.com/502238/ But the volume control labels were cut off by diff.  First is "DAC2 Analog" second is "Headset".  I will post a tarball with both amixer-before and amixer-after output shortly.
<mpoirier> GrueMaster: before and after what ?
<mpoirier> what's happening in between ?
<GrueMaster> I ran "amixer>amixer-before.txt" to dump default settings, then made changes in alsamixer, and redumped.
<GrueMaster> File is at http://members.dsl-only.net/~tdavis/beagle-audio.tgz
<GrueMaster> running amixer by itself will dump the current mixer settings/levels.  Then alsamixer can be used to visually change them.
<mpoirier> GrueMaster: you just typed "amixer" on the cmd line ?
<GrueMaster> yes
<GrueMaster> You do know how to use alsa utils, right?
<mpoirier> I do but I need to undertand exactly what you did to reproduce properly.
<mpoirier> The "alsamixer used to visually change them" part, is that through graphic interface ?
<GrueMaster> It is a console tool.
<GrueMaster> Open a terminal and try it.  It gives you direct control over the exposed audio controls through the driver.
<mpoirier> yes, just wanted to make sure we're on the same page.
<mpoirier> GrueMaster: I've been playing with sound for a while now thanks.
<GrueMaster> ok
<mpoirier> GrueMaster: how did you know it was "HeadsetL Mixer AudioL2" you had to un-mute ?
<mpoirier> is there a trick ?
<GrueMaster> Yea, open two terminal windows, start "speaker-test -c 2 -t wav" in one and tweak alsamixer controls in the other until audio is heard.
<mpoirier> AH !
<GrueMaster> Speaker-test will run untill <ctrl>-c.
<mpoirier> I love brute force solutions - thanks.
<GrueMaster> Well, I am a brute, so it's what I do.
<GrueMaster> :P
<Heff01> Hi, can anyone help enable svideo in Maverick Meerkat beta, on Beagle XM, over minicom
<GrueMaster> Heff01: I don't know if that has been tested or even enabled.  Not something that is easy to test here.
<Heff01> Stuck until I get hdmi to dvi d cable then
<PhilM> I left one in my cube when I left TI
<Heff01> doh
<PhilM> :-)
<Heff01> Only got board yesterday, just eager to get going
<PhilM> Micro Center carries them for $10US
<Heff01> I know, on GMT everythings shut
<Heff01> had svideo lying around
<Heff01> I guess it could be enabled thru xorg when booted
<Heff01> #android-arm
#ubuntu-arm 2010-09-29
<rsalveti> cooloney: hey!
<rsalveti> cooloney: any news about the mem issue bug?
<rsalveti> robclark: do you know if we're going to get the fb resize feature from the omap 4 x11 video driver?
<robclark> rsalveti: I guess the new pvr driver eventually.. although it would help to get DRM support into the kernel in a sane way for non PCI systems..
<cooloney> rsalveti: nothing new here.
<cooloney> rsalveti: i got the same result like you
<cooloney> 2G:2G split to disable highmem
<rsalveti> robclark: that's for sure..
<rsalveti> robclark: was thinking for maverick, how we're going to deal with people changing monitors, and even when we can't probe the correct edid when booting
<rsalveti> the case of my monitor
<rsalveti> cooloney: for me it's quite stable with 2G:2G, no highmem and using just one cpu, or no L2
<cooloney> yeah, that's ture
<GrueMaster> Need at least a sane default.
<GrueMaster> for monitor resolutions.
<cooloney> rsalveti: but one cpu might not be acceptable, i think
<rsalveti> GrueMaster: for default there's a bug currently for monitors that turns off and on during probe (my case)
<GrueMaster> I hit the same thing with my HDMI switchbox.
<rsalveti> that the screens turns 640x480 initially and then it changes to the correct one
<rsalveti> probably the same bug
<rsalveti> I'm looking at it now..
<GrueMaster> Except mine stays at 640x480.
<robclark> yeah, probably same bug
<rsalveti> cooloney: probably not, even without L2
<robclark> GrueMaster: pls send your edid.. /sys/devices/omapdss/display0/edid
<cooloney> L2 will have some impact to the performance
<rsalveti> that's the problem ...
<cooloney> rsalveti: so there is not good solution now,
<robclark> yeah, disabling L2$ or 1 cpu is not ideal.. but 768m has been relatively stable for me so far..
<rsalveti> GrueMaster: yeah, can you paste your edid when using the switchbox?
<cooloney> rsalveti: i also applied the patches in 2.6.35.4, 2.6.35.5 and 2.6.35.6
<cooloney> from stable tree
<cooloney> got the same result
<rsalveti> if we get a correct edid then it's just timing issues when probing the edid
<III> hey all... is current build having any issues?
<rsalveti> just if you're using omap 4
<GrueMaster> Erm, is there a tool for reading this?  It looks like garbage.
 * III is using omap4
<rsalveti> GrueMaster: yep, binary
<rsalveti> parse-edid
<rsalveti> III: currently when using 1GB we get build issues when building the kernel
<rsalveti> with highmem you can easily get it, without highmem you get it some times
<rsalveti> if we disable L2 or use just one cpu, everything works fine
<rsalveti> another workaround is to use 768MB (the one we're using now)
 * III moves to older build :D
<rsalveti> and if we don't fix it for the release, this will probably be the way to go
<rsalveti> cooloney: the problem is that it's quite hard to trace it, I'm out of ideas
<cooloney> rsalveti: me either, i tried to enable ftrace with dynamic tracing
<cooloney> but it took me lots of time to get some useless information
<rsalveti> it works fine with all mem stress software I use, but breaks when building the kernel
<rsalveti> cooloney: but were you able to get something?
<cooloney> rsalveti: i get function tracing information from the abort handler
<cooloney> and it changes every time before the abort handler
<rsalveti> cooloney: hm, can you paste it?
<cooloney> i think we need another simpler test case
<cooloney> rsalveti: np, man. let me find it. paste it to you guys
<rsalveti> cooloney: sure, but I tested a lot of mem stress software and unable to reproduce the issue
<robclark> GrueMaster: can you email me the binary?
<rsalveti> mem stress with disk io and etc, and nothing
<cooloney> rsalveti: cool, what are those mem stress test cases?
<GrueMaster> robclark: working on it.
<robclark> k, thx
<robclark> brb
<rsalveti> the problem probably happens with mem + i/o + dma
<GrueMaster> system is being real sluggish.
<GrueMaster> (actually, all networked systems are).
<cooloney> rsalveti: that combination is too complicated. sign
 * cooloney brb
<GrueMaster> http://paste.ubuntu.com/502398 - text version.
<rsalveti> cooloney: maybe something at arch/arm/plat-omap/iodmm.c, uses l2...
<GrueMaster> Gotta run.  I'm being drug away.
<rsalveti> GrueMaster: the problem at bug 644714 is that the resolution is not changed at the x11 driver
<ubot2> Launchpad bug 644714 in linux-ti-omap4 (Ubuntu) "Screen corruption waking from screen blank if no monitor present (affects: 1) (heat: 526)" [Undecided,New] https://launchpad.net/bugs/644714
<rsalveti> the fb is changed with latest code from robclark, but not x11
 * rsalveti out
<III> does anyone know of a good working build I can use? I just tried  20100926 and 20100927 but I am not able to boot.. anyone else seen this issue?
<III> sorry that is for OMAP4
<persia> What issue do you see booting?
<III> seems to hang on boot
<III> take that back... seems to boot in to busybox
<persia> Ah, good.  Not booting is complex.  Any messages before being dumped to a busybox prompt?
<III> no init found... I'm trying again but with a new card.
<persia> I had that on an upgrade, and was certain it was PEBKAC (and it was omap3), but maybe it wasn't.
<persia> ogra, So, it might be nice to have manifest files also for non-omap4 preinstalls :)
<persia> III, Hrm.  Please let me know if it works/doesn't work with the new card.  Seems 20100927 has the latest upstart, sysvinit, initramfs-tools which are the bits that are immediately suspicious (but the changelogs don't show anything worrisome).
 * persia waits for rsync for 20100927/omap for a parallel test
<ogra> persia, ??
<persia> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ : note the number of .manifest files
<ogra> oh
<ogra> did NCommander kill acorn again with extenbsive dove builds ? :=
<persia> I thought you were the person who put them in, and don't happen to know which bit to frob for that
<ogra> :P
<ogra> persia, manifers files are installed some point around bootloader install ;)
<persia> My issue isn't the lack of ...0928 images (although that's frustrating), but the lack of a manifest for the images that are posted.
<persia> And bootloader is broken for omap?
<ogra> the images without bootloader logically have no manifest (and no partition table either)
<ogra> was broken
<ogra> without a livefs i cant tell
<ogra> i would expect that archive to have settled by now though
<persia> On the 27th?  There *is* an omap livefs (or something using 509M compressed)
<ogra> wintout bootloader partition
<persia> Aha!
<hrw> morning
<ogra> just on a sidenote i have debian lenny running natively on the ac100 (with the existing kernly only somethin that old (and without update) works)
<persia> Would that also be why III couldn't boot?
<ogra> no, didnt affect omap4
<persia> Excellent!
<persia> Dunno then.
<ogra> i cant ifup the wlan card though
<ogra> something is blocking
<persia> driver issue?
<ogra> no, premission issue
<ogra> *per
<ogra> god, i cant type tofay
<ogra> *today
<NCommander> ogra: it was still running when it spit out hte last image
<NCommander> ogra: I need a package merged :-)
<ogra> NCommander, i was making a bad joke :)
<NCommander> can you review the patch so I can get the feature freeze exception?
<ogra> NCommander, post RC ?
<NCommander> ogra: bah, now I know this is reality. the real ogra doesn't joke :-/
<NCommander> ogra: its critical enough that I want to at least run it by the release team
<NCommander> ogra: if it flops, it flops, but I have to at least *try*
 * NCommander wants his ubiquity bug fixed :-/
<ogra> you can start uibiquity from the terminal, right ?
<NCommander> ogra: well, yes, but that's less than ideal
 * ogra wants his "rootfs fillt to 100% wint encrypted home" bug fixed ... but i wouldnt risk RC for that
<persia> ogra, Did you make a patch for that yet?
<ogra> thats really something you can release note
<ogra> persia, nope
<persia> It's a trivial patch, if you want to test it.
<ogra> but i expect to have one before end of the week
<persia> Ah, OK.
<ogra> oh,you worked on it already ?
<persia> Only in the sense of the IRC session a few days ago.
<ogra> sure i'll test :)
<ogra> ah, k
<persia> But it's < 15 lines of code :)
<ogra> yep
<ogra> NCommander, i'll review it (and nod it off if its ok) later today ... but i wouldnt push for getting it into RC (get it to the queue though)
<ogra> NCommander, the changelog disagrees with the change in your branch
<ogra> NCommander, scripts/casper/47une_ubiquity is missing completely
<NCommander> ogra: argh, i readded tha tand push it
<NCommander> Hold on
 * NCommander goes to get pants so I can turn the Dove on
<ogra> NCommander, also dont forget to check for executability (i cant see that in the LP UI) i dont remember which files need to be executable and which dont
<ogra> is your dove on the balcony ?
<NCommander> ogra: no, I'm just living in a place that if I walk to the room where the board is without pants, someone will scream
<ogra> the board is without pants too ?!?
<ogra> geez !
 * NCommander decides to discontinue this line of conversation
<ogra> check the quotes page :P
<NCommander> damn it
<NCommander> ogra: re-pushing. bzr hates me
<NCommander> (I miss git)
<ogra> bzr add isnt that hard :)
<NCommander> ogra: I just forgot to bzr push
<NCommander> ogra: its there and executable
<hrw> NCommander: there is git-bzr-ng project on github to provide "git bzr" plugin
<hrw> NCommander: I use it to manipulate bzr repos but so far failed to push with it
<ogra> NCommander, so why do you apt-get remove ?
<ogra> NCommander, i would bet it slows down booting a lot
 * ogra would just have removed the diversion instead of waiting for the package DB
<NCommander> ogra: because it also removes the desktop file oem-config installs asking to finalization the installation
<NCommander> ogra: well, I wanted to remove it during image building :-P
<ogra> NCommander, well, your call, butu i'D say it surely adds 10-20sec to the boot
<ogra> and ubiquity will remove it anyway
<NCommander> ogra: didn't see that bad, and ubiquity doesn't remove it until AFTER installation
<NCommander> Kinda confusing to have it there before you install
<NCommander> *seem
<ogra> whats confusing about it ?
<NCommander> if you want a livecd-rootfs patch, I already have one of those, though its not quite as tested (I can fix that though now)
<ogra> the user never sees it
<NCommander> ogra: er, yes theydo?
<NCommander> Its right therein Settings.
<ogra> no, i dont want to tinker with livecd-rootfs
<ogra> NCommander, where do you test for the arch ?
<ogra> i dont see any code for that
<ogra> currently your patch breaks all oem installs
<berco> good morning all
<NCommander> ogra: no it won't, because OEM installs don't install eom-config until after installation which doesn't use casper.
<ogra> the action should be arch (or even subarch) specific
<ogra> NCommander, i dont think thats true
<berco> anyone knows if there's a particular issue with building webkit on arm?
<ogra> NCommander, did you talk to superm1 about that ? i bet you break all dell installations with that
<persia> berco, Shouldn't be.  What issue are you seeing?
<ogra> (note i dont talk about the OSG team here but about oem's using modified images)
<berco> persia: It fails all the time
<berco> persia: wondering if not enough memory would be the issue
<NCommander> ogra: you can't hav eoem-config in the same image as installed ubiquity with the later working properly since it will hide the installer icon
<ogra> doesnt seem to fail for us ... http://qa.ubuntuwire.org/ftbfs/
<NCommander> ogra: I *wanted* to remove in livecd-rootfs, you said remove it in casper
<ogra> NCommander, well, every thought why superm1 added that diversion ?
<ogra> NCommander, no, i said remove the diversion
<NCommander> ogra: er, I think ev wrote that diversion
<NCommander> ogra: and that's the wrong bloody solution
<ogra> well, from casper, but you know what i mean
<NCommander> The package shouldn't be there
<ogra> the packages are there in some setups
<ogra> there is an OEM who uses an automated preseeded ubiquity to create images with oem-install
<NCommander> ogra: oem-config however is installed on fht elfy if its needed
<NCommander> That's why its in ship
<ogra> anyway, make it arch specific and i'll approve
<NCommander> Looking at oem-config code, the postinst doesn't handle the case if the diversion is already there
<ogra> i dont care if you fiddle with the diversion ... but i do care if you make it a default for everyone
 * NCommander will sit down at do it a bit later then
<ogra> remove it or remove the diversion ... as you like
<ogra> but make sure people explicitly installing oem-config dont get screwed by it
 * persia vaguely wonders why there are both "webkit" and "webkitkde" packages
<persia> berco, Seems to build on the buildds: https://launchpad.net/ubuntu/+source/webkit/1.2.4-1ubuntu1/+build/1948880
<persia> Might be RAM, might be missing patch.  Might be different version.
<ogra> looks like KDE needs an older version
<persia> That's not a good reason, but potentially.
<ogra> NCommander, was a meta uploaded for the dove kernel ?
<NCommander> ogra: no idea
<ogra> i though you'd care ... thats why i talked about it in the meeting yesterday
<ogra> though if you dont ...
 * ogra shrugs
<berco> persia: I was looking at that page too :). Argh!
<ogra> will probably break d-i though
<ogra> on dove
<persia> berco, My recommendation would be to compare your build log to the build log on LP and find the point at which they differ: this will probably be a hugely valuable hint to getting the build to work.
<berco> persia: do you know the board hubbard?
<persia> Never heard of it.
<berco> armel package was built on this board
<berco> on Launchpad
<persia> Oh, you mean https://launchpad.net/builders/hubbard ?
<berco> yes sorry
<persia> I believe that's a Freescale Babbage 3.0 board, but I could be mistaken.  Should be ~800MHz, ~512MB unless someone did something special compared with other implementations of that SoC I've seen.
<ogra> yes, all buildds are babbage 3.0
<berco> thanks
<NCommander> ogra: patch added and pushed via bzr. I can test a respun image you want to confirm the updated code
<ogra> NCommander, if Riddell allows ... triger a full set of armel then please
<NCommander> ogra: Riddell gave me permission to respin ARM at will
<NCommander> ogra: I meant a locally respun image
<ogra> oh, yeah, test it
 * NCommander groans
<ogra> http://pandaboard.org/
<hrw> ogra: yep.
<NCommander> ogra: the patch seems valid, but I'm having testing issues due to instability
<NCommander> ogra: I am going to commit a slightly newer version, and ask you to merge and handle getting the RC freeze exception, but hold off on the actual upload until I can get someone beside myself to reconfirm the test results
<persia> Does anyone still use redboot-imx?  Can it be dropped from the archive?
<GrueMaster> persia: our Lucid imx51 images use it.
<GrueMaster> afaik
<persia> GrueMaster, But do we need/want it in maverick?
<persia> III, Just FYI, there's a 0929 image that ought be in better shape.
<GrueMaster> True.  imx51 was disabled sometime around alpha 2-3.
<GrueMaster> iirc
<III> persia: thanks... just downloaded it
<mpoirier> ndec: do you think you could get me access to some ABE routing documentation ?
<rlameiro> mpoirier: you know, now ther is a #igep channel, could be easier to find igep testers now
<ndec> mpoirier: hi... sorry I saw your email, but didn't have too much time to digg into this.
<mpoirier> rlameiro: indeed, but I would really need to get a board.
<ndec> mpoirier: why do you need this info?
<rlameiro> mpoirier: If i was rich, i would buy you one :D
<ndec> mpoirier: I am not sure which document you would need in fact
<mpoirier> ndec: we are bound to repeat the current sound investigation on our other omap3 boards.
<mpoirier> ndec: omap4 too for that matter.
<ndec> mpoirier: ABE is OMAP4 only, this is a complete different solution for audio h/w on OMAP3
<mpoirier> ndec: the more I understand, the better I can give meaningful information to your team.
<ndec> mpoirier: sure...
<mpoirier> ndec: I suspected that much.
<mpoirier> ndec: I'm mostly interested by the process berco took to produce the omap4_sound_config.sh script.
<mpoirier> those commands come from some sound data somewhere and that's what I'm after.
<ndec> mpoirier: this file is produced by the audio dev team, not us. I will reply to your email.
<mpoirier> ndec: cool - you're my contact into that world.
<mpoirier> ndec: if I'd have some clue on how omap4_sound_config.sh and the SDP4430.conf were generated, I could help on my side.
<GrueMaster> rsalveti: RE:  Bug 644714  I have another edid output that essentially is blank.  THis is what I get when the system wakes and no monitor is attached.  The bad thing is, Xwindows is garbage, which is why I recommended 1024x768 as a fallback.
<ubot2> Launchpad bug 644714 in linux-ti-omap4 (Ubuntu) "Screen corruption waking from screen blank if no monitor present (affects: 1) (heat: 526)" [Undecided,New] https://launchpad.net/bugs/644714
<GrueMaster> I'll try to add the data after RC testing.
<rsalveti> GrueMaster: yep, this would explain the issue
<rsalveti> boot with edid -> 1440x900
<rsalveti> then when it gets back, finds no edid -> 640x480
<rsalveti> but the x11 continues to think the fb is 1440x900
<GrueMaster> Well, 640x480 is absolute garbage.  looks like 4 screens side by side only partially drawn.
<GrueMaster> Can't get a screen capture atm.
<rsalveti> GrueMaster: I get this with my monitor: http://www.flickr.com/photos/rsalveti/4932601965/
<GrueMaster> That is actually usable.  Mine is much worse
<GrueMaster> I'll try to get a capture during testing.  Heavily into RC atm.
<rsalveti> GrueMaster: np
<robclark> hrw: is there some trick to install your cross compiler packages on a lucid box?
<robclark> Package libmpfr4 has no installation candidate
<hrw> robclark: http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ for amd64
<hrw> robclark: i386 in next few days
<robclark> perfect, amd64 is what I need
<hrw> robclark: libmpfr4 is in maverick
<hrw> robclark: maverick pacakges on p.c.c. are obsolete anyway
<robclark> yeah.. but I was trying to use your maverick PPA on lucid..
<robclark> let me try this other site instead
<hrw> ppa is also obsolete
<hrw> I just keep both because some toold use them
 * robclark can't keep track of what isn't obsolete
<hrw> for maverick: use maverick archive. for lucid: use what i just gave you
<robclark> k, will do
<robclark> ohh..  I think it's working :-)
<mpoirier> rsalveti: you have a significant head start on b644714 due to your previous work on EDID.  Do you have the cycles to work on it or you'd be happy to offload it ?
<rsalveti> mpoirier: I'm working on it today
<mpoirier> ok
<rsalveti> first debugging the issue when booting and activating/deactivating the hdmi with my monitor
<rsalveti> and then the x11 part
<GrueMaster> mpoirier: on the omap4 sound issue, this should probably be changed to libasound2 instead of the kernel, as libasound2 contains all the /usr/share/alsa/cards/*.conf files.
<GrueMaster> Thoughts?
<GrueMaster> I have the same issues with Beagle (omap) and now Dove A0.
<mpoirier> humm... there is also a kernel portion of it.
<mpoirier> the TI patch for omap4, and some work to differentiate card on beagle and others.
<mpoirier> as you said, there will be a libasound2 part of it.
<GrueMaster> Ok.  Guess I should file separate bugs for each system then.
<GrueMaster> Or should we just track them all centrally?
<persia> Better to have multiple tasks for one bug.
<persia> "Also affects distribution ..."
<mpoirier> is there a way do link two bugs in lp ?  i.e this bug will only be completed if that bug is completed...
<persia> I should say "Please file one bug per platform, with as many tasks for each bug as are required to address the issue."
<persia> mpoirier, Intentionally not (although debate continues on this subject)
<GrueMaster> We either have one main bug and list all the kernels & asound, or one bug for each kernel.
<GrueMaster> Oh, ok
<persia> I think we should have one bug for each *board*, and list asound & relevant kernel for each.
<GrueMaster> persia: That makes the most sense.
<persia> Potentially list multiple kernels for a single board if it's supported by multiple kernels and multiple kernel maintainers want to apply the same class of patch (e.g. for omap3)
<mpoirier> GrueMaster: I also think we should have a bug per board.  Otherwise bugs never get closed.
<mpoirier> as persia indicate, the fixes will span multiple kernels.
<persia> mpoirier, Only in cases where multiple kernels support a given board.  For some hardware (e.g. imx51), there may only be one kernel available.
<persia> Ideally, this is a short-term thing, until linaro fixes things so that there is only one true kernel.
<prpplague> http://www.elinux.org/Panda_Bamboo
<prpplague> for anyone that is interested, the deadline for features for the bamboo board is october 8th
<robclark> prpplague: IR receiver?
<robclark> (and lasers... sharks with lasers)
<prpplague> robclark: hehe
<prpplague> robclark: i have IR on my list to look at
<robclark> cool
<persia> Talk of SATA was for a different extender, right?
<prpplague> persia: still trying to figure that out
<prpplague> persia: i'm considering dropping the second sd/mmc in favor of a 32GB eMMC
<persia> Unless you can find a way to boot off that, I'd rather see a second SD/MMC.
<prpplague> persia: boots fine
<persia> Off a secondary eMMC?
<prpplague> yea, same as blaze
<persia> Oh, please do that then.  I'd dearly like to return to having a sane "install" path.
<persia> And I'll have good arguments to do that if the Bamboo works with it :)
<persia> (extra benefit: the same codepath would work for both panda and blaze, etc.)
<bjf> GrueMaster, did that fsl-imx51 kernel show up for you yet?
<GrueMaster> Not sure, will check.
<bjf> GrueMaster, https://launchpad.net/ubuntu/+source/linux-fsl-imx51/2.6.31-608.20/+build/1978184
<GrueMaster> I know it is listed on launchpad.  But until it shows up in http://ports.ubuntu.com/pool/main/l/linux-fsl-imx51/, it is more difficult to deal with, and it still isn't there.
<bjf> GrueMaster, ok, trying to figure out where it's hung up
<persia> If it's not published by the turn of the next hour, might ask if the release team has the publisher on manual.
<GrueMaster> persia: This is for lucid-proposed.  Shouldn't be affected afaik.
<persia> bjf, I haven't checked current performance, but it used to take 43-103 minutes to get from "built" to "available in the archive"
<persia> GrueMaster, it's the *same* publisher.
<bjf> persia, thanks for the info
<GrueMaster> ah
<GrueMaster> Well, since I'm deep into Maverick RC testing, it will have to wait until Late tomorrow/Friday for testing.
<bjf> GrueMaster, np, mostly i'm just trying to make sure its available to you when you are ready to work it
<lool> ogra: Around?
<GrueMaster> Well, now this is odd.  Attempted to change only the font in une-efl, the system seems to have completely changed themes.  Very unusual.
<hans2> Question: Is there any progress being made with suspend on imx51?
<GrueMaster> A new kernel was uploaded yesterday, but I'm not sure what was changed in it.  It is currently pending publication after Maverick RC freeze is lifted.
<ogra_ac> rc freeze for a lucid SRU ?
<ogra_ac> GrueMaster, it should just go in
<ogra_ac> should be in -proposed for testing if it has build
<GrueMaster> Well, that's what I have been told.  I'm too busy with RC to go hunting for it.
<GrueMaster> And the kernel team just keeps sending me links to launchpad where the packages are sitting.  Need it in lucid-proposed for apt-get to pull.
<persia> GrueMaster, The acceptance queue is different from the publisher.
<ogra_ac> lool, yes (as long as this tegra WLAN stays stable)
<GrueMaster> persia: I don't really care about the background processes and the mechanisms that they work through.  What I do care about is when I get an email requesting me to test a kernel update in lucid-proposed, and people asking me why it isn't there for apt-get to work.
<persia> GrueMaster, That's fair: it's sensible for the uploader to take responsibility for ensuring the upload ends up being distributed in the repositories.
<GrueMaster> my point exactly.  :P
<persia> Anyway, I'll continue to explain workflows and background processes and mechanisms as long as people ask questions.  Appropriate folk (e.g. bjf) might want to chase up on things.
<GrueMaster> explaining them is fine, as long as they are also addressed to the people that should be able to do something about the process when it doesn't work.
<bjf> persia, i'm interested in the workflows and background processes so i appreciate the info
<persia> GrueMaster, Sorry then, I'll try to read more carefully and not mis-highlight.
<GrueMaster> Don't get me wrong, I too am interested.  Just not when I have 1 day to test multiple releases on multiple platforms.  :P
<persia> bjf, So, anyway, once LP gets a build, it submits it to the queue (e.g. https://launchpad.net/ubuntu/lucid/+queue ).  The queue has a few states, and things can be in one or another depending.  Nothing will land in the archives until it gets to Accepted (NEW and UNAPPROVED need manual action by an archive-admin).  Stuff in Accepted will be pushed to the archive each publisher run (typically once an ho
<persia> ur: sometimes set to manual for release management purposes).
<persia> bjf, So, find out where your package is: if it's not anywhere in the queue (including DONE), then something is odd with the LP build.  If it's in the queue, but not ACCEPTED or DONE, you need an archive-admin (and likely some associated paperwork).
<persia> best place to find archive admins is #ubuntu-devel
<persia> If it's been in ACCEPTED for a couple of hours or more, and it's around some special time in the Ubuntu Release schedule, you might check with the folk in #ubuntu-release to make sure the publisher is running.
<bjf> persia, there isn't a way for me to check if the publisher is running without asking?
<persia> I think only LOSAs can check, but there may be some other interface exposed.  You could ask in #launchpad, but I generally just assume it's running except when it clearly hasn't for about 3 hours.
<dcordes-lib> Hi. Is anybody aware of fast mirrors to the arm preinstalled daily builds ?
<persia> I believe they are all private.
<dcordes-lib> Hm. Currently only getting around 50kB/s from cdima.ubuntu.com
<dcordes-lib> but it might be the library hating me
<dcordes-lib> ah seems to be a local problem really
<dcordes-lib> 3,3MB/s now
<persia> That's a much better speed :)
<dcordes-lib> Bye
<Neko> persia, all ubuntu boxes shipped, exactly the numbers from the email
<persia> Neko, Cool.  Thanks for the confirmation.  Please let me know if anything isn't happening to your satisfaction.
<Neko> I expect about a month while people get used to it
<Neko> they all shipped with maverick+xfce but I assume the kde guys etc. will wipe it immediately
<persia> Shipping with maverick will make lots of folk happy.  I hear markos_ is coming to UDS, and I suspect people will be asking questions there.
<robclark> so quick question.. does dkms log to somewhere, so I can see *why* it failed to rebuild some module?
<lool> robclark: perhaps in /usr/src?
 * robclark looks
<robclark> hmm.. src is there.. but don't see a log..
<robclark> ok.. well, I think I figured out how dkms is invoked, so I can do this manually..
<rsalveti> robclark: yep, /var something, let me see it
<rsalveti> had the same question when I created the sgx package
<rsalveti> make.log, something like that
<robclark> rsalveti: the sgx package is the one I'm having trouble with ;-)
<rsalveti> in my case it was /var/lib/dkms/powervr-omap3/3.01.00.07/2.6.35-22-omap/armel/log/make.log
<rsalveti> robclark: well, I created only the omap 3 one :-)
<robclark> ahh,  perfect.. found the log.. thx rsalveti
<rsalveti> np
<robclark> hmm.. tho the log has no errors..  I wonder why dpkg thought it failed when I tried to install new kernel?
<rsalveti> robclark: can you paste the error you got?
<rsalveti> could be that it couldn't find the proper headers for your kernel
<robclark> http://paste.ubuntu.com/502859/
<ndec> robclark: it looks like you are installing the wrong headers. the OMAP4 kernel should be linux-headers-2.6.35-903
<ogra_ac> robclark, you are building omap3 stuff
<robclark> ahhh...
<ogra_ac> apt-get install linux-headers-omap4 iirc
<rsalveti> robclark: yep, that should be your problem
<ogra_ac> (there is a metapackgae for everything ;) )
<rsalveti> even a meta of the meta
<robclark> heheh
<ogra_ac> heh
<ndec> robclark: you probably want to remove the omap3 kernel and headers packages as well.. that said it's probably a bug in our sgx omap4 package... it should not try to build/install on non supported kernel
<robclark> ndec: well.. I was just trying to install a self-built kernel, and keep the sgx stuff working..
<ogra_ac> ndec, well, it also was a bug that foreign headers were installed at all
<ogra_ac> thats fixed since a few days
<ndec> robclark: argh... self built, you mean as ubuntu packages? or just uImage.
<ndec> ogra_ac: cool
<robclark> ndec: .deb...  make CROSS_COMPILE=... ... deb-pkg
<ndec> robclark: ok. you will need to generate the headers too.
<robclark> well... I guess headers should be same as what I already have... I just git pull'd the kernel-ubuntu tree from d.oz.o..
<robclark> hmm.. I guess I shouldn't have tried to reboot
<ndec> robclark: the next problem... will be that sgx module will likely not natively build if your kernel has been cross compiled... just fyi: native kernel compilation as .deb should take ~2.5 h on panda
<robclark> :-(
<robclark> fwiw, I am using the linaro cross compile toolchain to build kernel.. so same gcc version
<ndec> robclark: the compiler is not the problem... but the generated tools and makefile during kernel build will assume cross compile. when compiling module natively with dkms, it's causing issues. I don't know all the details, but rsalveti or sebjan might know
<robclark> doh..
<robclark> modules are such a pain
<robclark> but ok... I can cross compile the modules too
<Neko> var/cache/fontconfig/99e8ed0e538f840c565b6ed5dad60d56-mipsel.cache-2 <-- what does mipsel mean?
<Neko> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501700 REALLY? "fixed in latest fontconfig"??
<ubot2> Debian bug 501700 in fontconfig "writes cache files with "mipsel" in name .. on armel" [Minor,Fixed]
<Neko> well now it says le32d8 or so which I guess is less retarded but.. why would the cache file need to be so arch specific like that.
<persia> "mipsel" is little-endian MIPS
#ubuntu-arm 2010-09-30
<GrueMaster> rsalveti: Still hanging around?
<rsalveti> GrueMaster: yup
<GrueMaster> Interesting info on our audio issues.  Quick update:  Dove & panda are new hardware for this cycle, hence new bugs.  Beagle, however, works with lucid, fails with maverick.
<rsalveti> GrueMaster: but new kernel for beagle, that could explain
<GrueMaster> new everything.  New kernel, new alsa, new pulseaudio...
<GrueMaster> Lots of variables.
<rsalveti> true
<GrueMaster> And I have eliminated the kernel for the most part, as I can run speaker-test just fine.
<rsalveti> hm, ok
<GrueMaster> Oh, and btw, our own David Henningsson has created an alsamixertest script that should help in figuring out what needs to be in alsa.conf.
<GrueMaster> https://launchpad.net/~diwic/+archive/maverick
<GrueMaster> I haven't tested it yet, but I have built it for armel.
<GrueMaster> Requires a loopback cable (hp<>mic), and all mine are currently tied up.
<rsalveti> hm, cool
<rsalveti> if you want to test that with panda, I sent you an email with latest deb, that has probably everything we need from the kernel side
<GrueMaster> At any rate, it has been a long day of testing.  I'm going to backup this fresh lucid image on my beagle, then kill it with an upgrade.
<rsalveti> setting up the card name and everything
<GrueMaster> Yea, I saw the email  Also planned on doing that before I call it quits.
<rsalveti> cool
<rsalveti> berco: can you share with us the file /usr/share/alsa/cards/SDP4430.conf? want to test with latest audio patch series
<rsalveti> I'm already getting SDP4430 - SDP4430 from /proc/asound/cards
<Xase> ... Can anyone assist me in setting up an ARM toolchain for ubuntu x86
<persia> Xase, What are you seeking to accomplish?
<rsalveti> Xase: with maverick you just need to isntall the correct packages
<Xase> To build the android Kernel for an arm device.
<Xase> /bin/sh: arm-eabi-gcc: not found
<Xase> I have Maverick.
<Xase> What packages?
<rsalveti> gcc-4.5-arm-linux-gnueabi for example
<Xase> ...
<persia> Xase, Which release are you running?
<rsalveti> just give apt-cache search arm-linux
<Xase> Well that would explain that's why I couldn't find it.
<Xase> Lol
<rsalveti> you should see the cross packages
<Xase> I had no idea that's what apt-cache did.
<Xase> Man... I wish there was a "ubuntu-phone" I could be running instead.
<Xase> Or if MeeGo was a little more... well going.
<Xase> :D
<persia> Xase, It's called "Kubuntu-Mobile"
<Xase> No effin way >_>
<persia> Mostly gets tested on the n900s
<Xase> ... I almost bought one of those.
<persia> But needs a few hacks, because the n900 kernel isn't open, etc.
<persia> Also works for i386 phones (but actually doesn't have the driver for the baseband chip in my x86 phone)
<rsalveti> the kernel is open
<Xase> ... there are x86 phones?
<persia> rsalveti, Not according to the kubuntu-mobile guys 12 hours ago.  Are you sure?
<Xase> Now you're just blowing my mind.
<persia> Xase, Yes, but this isn't the best channel to discuss them :)
<rsalveti> persia: well, afaik yes
<Xase> Of course not.
<Xase> But now I must google explosively.
<rsalveti> you could try upstream + additional patches from the stock kernel
<persia> rsalveti, Maybe some closed drivers or something?  I dunno: there's a special procedure.
<rsalveti> you can grab the kernel sources from it
<rsalveti> generally you should just take care of the battery and watchdog stuff
<rsalveti> to avoid random resets
<Xase> Hmm
<Xase> still reports: /bin/sh: arm-eabi-gcc: not found
<persia> rsalveti, You might want to touch base with rbelem and ian_brasil: they'd love to have a less complicated procedure :)
<persia> Xase, Which release are you running?
<Xase> Maverick.
<rsalveti> Xase: after installing the correct packages you should see arm-linux-gnueabi-gcc
<rsalveti> persia: sure, I worked with them directly at indt already, will try to ping them later
<persia> And if your build file needs arm-eabi-gcc, you'll have to modify the build file.
<rsalveti> to understand what's going on :-)
<Xase> /bin/sh: arm-eabi-gcc: not found
<persia> rsalveti, I thought you'd find them familiar names :)
<Xase> ln -s arm-linux-gnueabi-gcc arm-eabi-gcc ?
 * rsalveti listening a cool mp3 from temple of the dog at his omap 4 board 
<rsalveti> with latest patches
<Xase> Wouldn't just a symbolic link be fine?
<rsalveti> but still manual work on alsa side
<rsalveti> Xase: question is, why?
<rsalveti> your build script is the wrong guy here
<Xase> ... so I don't have to keep modifying stuff.
<Xase> I didn't create the build script.
<Xase> Blame Google.
<rsalveti> well, you can then create a link and mess with your system :-)
<rsalveti> but I guess that at least this part is expected from you to change it
<rsalveti> it's the cross-compiler
<Xase> So you'd instead recommend just modifying the build script?
<rsalveti> yup
<rsalveti> cooloney: I think I found a possible culprit for the mem issue
<rsalveti> cooloney: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=commitdiff;h=644bab98ce980246e6b945962fec9a733a48c325;hp=adaf930e8ae3eaca5d8eda744dfce96caf71447e
<rsalveti> cooloney: at http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-ti-omap4-1gb I added the previous patches and this latest one on top
<Xase> Darn that's inexplicably complicated at the moment.
<Xase> Lemme find my CTRL+F
<rsalveti> cooloney: you can find the deb file at http://people.canonical.com/~rsalveti/maverick/kernel/es2/linux-image-2.6.35.3+_2.6.35.3+-87_armel.deb if you want to test it
<cooloney> rsalveti: got it, awesome man
<rsalveti> I'm running the 5th build atm, no issues
<rsalveti> without highmem
<rsalveti> if I use highmem I'll always get this problem
<cooloney> rsalveti: yeah, let me try it. 2G:2G split right
<rsalveti> cooloney: we were missing one errata for pl310
<rsalveti> cooloney: then I found that at the upstream l-o we already got a patch that selects the errata by default
<rsalveti> just did the same thing
<Xase> bah arm-eabi-gcc isn't specified in either Kbuild or Makefile >_>
<cooloney> rsalveti: so even we enable this errata for pl310, we still needs 2G:2G split and npitre's patch, right?
<cooloney> without highmem
<rsalveti> cooloney: yup
<cooloney> rsalveti: thanks, got it
<rsalveti> cooloney: that could be at least one workaround to use 1gb
<rsalveti> while we try to debug the highmem issue
<rsalveti> but would prefer to test highmem with upstream
<cooloney> rsalveti: yeah, just in time, a workaround to us 1G for our release
<rsalveti> but even getting the mmc fix, couldn't get it recognized with upstream kernel
<cooloney> rsalveti: yeah, i tried patches in l-o list for mmc of es2.0 board, but the same as you
<Xase> arm-linux-gnueabi-menuconfig?
<Xase> nm
<Xase> I'm reading wrong.
<rsalveti> cooloney: description of the errata: http://paste.ubuntu.com/503055/
<Xase> so wrong.
<Xase> Just do yourself a favor and put me on the ignore list.
<rsalveti> cooloney: so it seems this could be our culprit, just need more testing
<rsalveti> will let it building during the night and check it tomorrow
<rsalveti> but so far so good
<rsalveti> 2cpus, with l2, 2g:2g and 1gb support
<Xase> BAH
<Xase> ...
<Xase> Wow.
<Xase> I guess this is goodbye guys.
<Xase> I just rm'd the arm asm
<Xase> from the project file
<cooloney> rsalveti: great, man,
<cooloney> rsalveti: i will post your patches with npitre's again
<Xase> Sweet. Nevermind.
<Xase> I need sleep.
<rsalveti> cooloney: with highmem I can easily get Unhandled fault: imprecise external abort
<Xase> ...
<rsalveti> so probably another issue
<rsalveti> cooloney: cool, just let do some more testing and then we can post it
<Xase> Too tired 2:49 AM... something about supporting nothing but the Calgary with this source >_>
<rsalveti> *lets
<cooloney> rsalveti: without highmem, it looks like l2 controller pl310 is the root cause. So this errata is necessary.
<cooloney> rsalveti: i agree with highmem, it is different from pl310 errata issue.
<rsalveti> cooloney: yeah
<rsalveti> there's also some more l2x0 patches going upstream: http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk
<rsalveti> and sram fixes at http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap_for_2.6.37
<cooloney> rsalveti: yeah, i reviewed that before. those l2x patches are for kexec implementation on omap4
<cooloney> and it follows Thomas Gleixner's generic one
<rsalveti> yep
<persia> kexec is awfully nice :)
<cooloney> persia: heh, need more testing and backport some patches to enable that.
<rsalveti> maybe with 2.6.37 on N :-)
<persia> No worries.  I think I need two more cycles before we depend on it :)
<Xase> ... gaddangit
<Xase> I've messed up my source.
<Xase> Gotta read the config a bit more clearly >_>
<Xase> Well see, because I couldn't get it to compile I had modified a ton of crap, so now using the plain source... it compiles out of box.
<Xase> Thanks #ubuntu-arm
<persia> Xase, So it's working for you now?
<Xase> Kind of...
<Xase> Still getting this "message"
<Xase> arch/arm/mach-msm/board-mot.h:125: error: #error Calgary is the only HW supported by this release
<Xase> And that's after using the source directly from the Calgary source page.
<Xase> I have no clue what it means though so... shrug.
<persia> And you're targeting a Calgary device?
<Xase> Anyways... anything I can do to help Ubuntu-arm out.
<Xase> Yes Persia.
<Xase> Also known as the Motorola Devour.
 * persia suspects some subtle machine definition in the cross-compiler somewhere.
<Xase> Should... I speficy TARGET=Calgary ?
 * persia has no information about the source being compiled.
<Xase> I'm new to any sort of compiling outside of software...
<persia> If that's a sensible option, try it.
<Xase> It's the source for the Calgary Device.
<persia> Note that you'll probably get better advice about the specific compilation steps from a Calgary-specific resource (wiki, forum, channel, mailing list, etc.).  We mostly focus on running Ubuntu native on ARM.
<persia> (with a wink and nod at limited cross-compilation)
<Xase> TARGET_PRODUCT=calgary makes sense =/
<Xase> Yeah.
<Xase> Kind of figured.
<Xase> If there was anything for the Calgary.
<Xase> It's an end-of-lifed device.
<Xase> But I am better off asking in Android perhaps ;)
<Xase> Again, is there anything I can do to help test/debug ARM Ubuntu?
<persia> Xase, If you happen to have hardware that can run it (e.g. Netwalker, Efika MX, Beagleboard, IGEPv2, Efika SmartBook, etc.) and want to help test and fix bugs, that would be great.
<Xase> =( I will try
<Xase> I might be able to attain something
<persia> If you don't have any of that, but have other ARMv7+VFP capable armel hardware with a working (recent) linux kernel, please try our userspace.
<berco> rsalveti: sorry, I didn't see your post earlier
<berco> rsalveti: I just attached the file to bug #637947
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/637947
<berco> rsalveti: do you have all you need kernel wise?
<NCommander> ogra: you about to help merge? :-)
<sveinse> If I want to make a maverick target image, which version of rootstock should I use?
<persia> sveinse, theoretically, anything ought work to some degree, but 0.1.99.4 would be most likely to have the best support.
<sveinse> thanks
<dcordes> Hi. Can somebody point to the oo.org build time problem ?
 * dcordes drops a pin
 * ogra shades his ears from the noise
<dcordes> ^^
<dcordes> I see a disruption of the force in 09-29 image
<dcordes> it won't start oemconfig althoug I have the semephore set
<ogra> hmm, has been tested a lot though (since it's the RC candidate)
<ogra> what arch ? omap or omap4 ?
<dcordes> ogra: I picked the omap4 and applied the few changes as usual
<ogra> "the few changes" ?
<dcordes> it's not much really
<dcordes> I install my kernel modules
<dcordes> add few networking scripts
<dcordes> and do
<dcordes> 'touch /var/lib/oem-config/run'
<dcordes> usually after that, I start the rootfs and it will run oemconfig
<dcordes> no problems
<ogra> yeah, it surely does for us
<dcordes> It might be corruption then. I see some error message:
<dcordes> Use of uninitialized value $item in hash element at /usr/share/perl5/Debconf/Format/822.pm
<ogra> yeah, smells like
<dcordes> need to get to the library and download the new image @ 3,3MB/s againm
<rsalveti> berco: thanks
<rsalveti> berco: got the file from latest proposed tree with tons of sound patches
<rsalveti> *kernel
<cooloney> rsalveti: i am going to post out our highmem issue workaround patch including your pl310 errata one.
<cooloney> rsalveti: do you think we need more test
<rsalveti> cooloney: well, just saw that I'm going to the 10th build here
<rsalveti> no issues
<rsalveti> so it seems better
<rsalveti> cooloney: were you able to test?
<rsalveti> i just tested using usb, didn't test yet with mmc
<rsalveti> but you can propose it, np, it's a fix anyway that we're not using atm
<cooloney> rsalveti: yeah, i tested it on my mmc, just 1 build, it passed.
<cooloney> rsalveti: ok, let me post it firstly
<rsalveti> cool
<cooloney> rsalveti: you know, it is quite slow for me to connect with ports.ubuntu.com
<cooloney> rsalveti: drive me crazy
<cooloney> rsalveti: i will test audio fixing tomorrow.
<rsalveti> yeah, can imagine
<cooloney> rsalveti: thx for the testing, it seems like that you're never sleep
<rsalveti> cooloney: I try to :-)
<rsalveti> cooloney: I saw you changed my patch to change just the config file
<rsalveti> while it works for us, as we build just one flavor, I decided to change the Kconfig because this was the same change that went upstream
<rsalveti> that would fix the issue for all ARCH_OMAP4 boards
<rsalveti> but I'm ok with your patch, just to let you know why I changed the Kconfig :-)
 * rsalveti lunch
<robclark> hmmm...
 * robclark somehow manages to murder an mmc card with fdisk..
<GrueMaster> btdt.
<GrueMaster> I usually end up doing a complete nuke at that point.  dd if=/dev/zero of=/dev/<SD Card>
<robclark> no... I no longer even get a device file for the card
<GrueMaster> ouch
<GrueMaster> May need to reboot.
<GrueMaster> Also, I discovered on one of my cards that one of the plastic guides on the side near the contacts had bent covering the contact.  Breaking it off fixed it.
<GrueMaster> ogra_ac: For the release notes:  upgrading beagle from lucid->maverick can run of of free space if USB drive is 4G or less.  Haven't tried yet on larger.
<ogra_ac> mind to talk to skaet and add it to the wiki `
<ogra_ac> ?
<GrueMaster> I'll drop a not on #u-release.
<GrueMaster> note even.
<prpplague> ogra_ac: ping
<ogra_ac> prpplague, i'm here
<prpplague> ogra_ac: hey, we were discussing possibly using a usb->sata on the bamboo board
<prpplague> ogra_ac: any thoughts on that?
<ogra_ac> you will be easily maxing out the USB with that i guess
<ogra_ac> the babbage imx51 board has such a setup, not really an advantage over a simple external USB disk
<prpplague> well the EHCI through put it pretty stable
<prpplague> ogra_ac: are they using OHCI or EHCI ?
<ogra_ac> ehci
<ogra_ac> ~24MB/sec reported by hdparm
<prpplague> ahh
<ogra_ac> and i doubt you can get much more through USb
<ogra_ac> so i guess just attaching SATA to the USB bus wont really gain much over a cheapo external USB disk directly attached to USB
<prpplague> yea that is kinda of why i didn't consider it
<prpplague> other than size of storage
<ogra_ac> i thought there was a way to attach it differently ?
<GrueMaster> It would be nice for convenience, but won't enhance performance.
<ogra_ac> gpio?
<prpplague> ogra_ac: it is possible to do PATA via the GPMC, and then use a PATA->SATA bridge
<robclark> prpplague: maybe even PATA is fine.. I think they still sell those
<ogra_ac> ah
<robclark> ;-)
<ogra_ac> GPMC, right
<GrueMaster> Hmm.  PATA<>CF would be interesting.
<ogra_ac> yeah, even PATA would rock
<prpplague> GrueMaster: PATA to CF is pretty easy
<prpplague> the only thing that would have to be done is a kernel driver to "work the gpmc" like a PATA interface
<GrueMaster> Yes I know.  I have 3 running systems that way.  Fileserver, firewall, and serial-console monitor.
<robclark> prpplague: well get crackin!  ;-P
<robclark> GPMC->PATA would probably drive two hd's, wouldn't it?  A master and slave..
<prpplague> robclark: gotta finish current project first
<GrueMaster> Pfft.  Multitask.
<GrueMaster> :P
<prpplague> robclark: not sure i have enough chipselect signals to do two
<robclark> hmm..
<robclark> prpplague: I guess I don't need both LED's..  depopulate one, some blue wire, and use that gpio as an extra CS?
<prpplague> robclark: negative
<prpplague> robclark: the controls need to be tied to the gpmc controller
<prpplague> robclark: the gpmc has it's on chipselects and such to control memory read/writes
<ogra_ac> ARGH !!!!
<ogra_ac> who designed the pandaboard.org page !!!!!
 * ogra_ac just linked the logo in a blog post ... 
<ogra_ac> at least i thought i link the logo
<ogra_ac> sigh
<ogra_ac> the whole page is a jpeg
<GrueMaster> Heh.
<ogra_ac> what an insanity !!
<rsalveti> ogra_ac: hehe
<rsalveti> they asked already to change to at least a png
<ogra_ac> that wont make it smaller though ... i just bloated planet.ubuntu.com with it
<robclark> I don't know what you guys are talking about...  pandaboard.org looks fine in lynx ;-)
 * robclark ducks
<ogra_ac> LOL
<GrueMaster> HA
<robclark> ogra_ac: maybe orbarron could send you a more appropriately sized logo?
<ogra_ac> robclark, well, its fine now
<ogra_ac> i'll just live with the embarrasement
<gourneau> Can rootstock be used to build debian root fle systems?
<ogra_ac> gourneau, i dont think anyone tested that ever
<dcordes> ogra_ac: any ac100 kernel news ?
<gourneau> Maybe it will be me then, I want to use Ubuntu.  How are the seed images defined?
<ogra_ac> dcordes, see planet.ubuntu.com
<ogra_ac> (no, no kernel news, but fully working images
<ogra_ac> )
<dcordes> ogra_ac: ah well didn't see any user space problems ..
<ogra_ac> dcordes, plenty
<dcordes> the SoC doesn't support neon right ?
<ogra_ac> right
<dcordes> what userspace related problems do you see ?
<dcordes> did you create a meta bug ?
<ogra_ac> android kernel
<ogra_ac> no
<ogra_ac> i dont think you will see any official support for the device any time soon
<dcordes> haha sometimes you make me laugh
<ogra_ac> feel free to create one though
<dcordes> I am looking to make things work, not if they will magically fix.
<ogra_ac> dcordes, thne tak to phh in #ac100 :)
<dcordes> I know the bum
<ogra_ac> *then talk
<ogra_ac> he has done a lot of low level stuff
<ogra_ac> and is still doing
<dcordes> without kernel source ?
<ogra_ac> well, there kind of is kernel source
<ogra_ac> its not as if there wouldnt be public branches of tegra eclair
<dcordes> now you got me all confused
<ogra_ac> the kernel supports modules ;)
<ogra_ac> you cant change the core indeed
<gourneau> Does anyone know of a good Ubuntu tablet about 7 inches, with a host USB port.  The smartq v7 is the best I can find.
<dcordes> gourneau: htc hd2 but you need to supply external power for the usb and the display is not 7 inches
<ogra_ac> and you can run ubuntu natively ?
<orbarron> orga_ac: pandaboard.org is a temp site for now... plz forgive the jpeg
<dcordes> ogra_ac: yes
<dcordes> ogra_ac: http://vimeo.com/14630263
<ogra_ac> orbarron, i dont care about jpeg, i care about that i right clicked the logo and pasted ion my blog post ... now my post has the whole site in it
<dcordes> ogra_ac: with full snappyness
<dcordes> lol bluepaste :>
<GrueMaster> ogra_ac: Do any of our initramfs scripts touch nand on beagle?  I keep getting nand i/o errors on mtdblock0.
<ogra_ac> GrueMaster, nope
<GrueMaster> But only after upgrading lucid to maverick (which replaces the kernel in nand).
<ogra_ac> GrueMaster, not in maverick
<GrueMaster> Very odd.
<GrueMaster> That's what I thought.
<ogra_ac> oh, upgrade is different
<ogra_ac> that still uses nand indeed
<GrueMaster> No, this is running a preinstalled image.
<dcordes> Is there any known breakage in 27th omap4 preinstalled image ?
<GrueMaster> But I only get the error if the maverick kernel is also in nand.
<GrueMaster> dcordes: Use the 29th.  It will be the official RC.
<dcordes> GrueMaster: ok I downloaded it already but had some strange problem
<dcordes> sounds like it must be on my end if you consider it for RC
<dcordes> somebody interested in adding HTC HD2 maverick RC infomration in planet ?
<dcordes> then we have covered the full embedded family
<dcordes> smartbook, dev board and cell phone
<dcordes> nevermind :)
<devilhorns> grrrrr
<devilhorns> someone needs to spank the icon designers
<ajay> hi all , i have igep board but in minicom i am getting message as ï¿½ï¿½ï¿½ï¿½
<ajay> no boot prompt
<GrueMaster> devilhorns: Are you referring to bug 651391?
<ubot2> Launchpad bug 651391 in gnome-control-center (Ubuntu) "Changing desktop font changed entire theme appearance in une-efl (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/651391
<devilhorns> GrueMaster, no, gimme a sec, I will show you my "gripe" :)
<rsalveti> ajay: probably missing x-loader and u-boot
<ajay> but green light is glowing on that board
<devilhorns> GrueMaster, ok, keep in mind when you look @ this, that my code does everything properly (in that it centers the icons)
<devilhorns> http://home.comcast.net/~devilhorns/files/unity_efl.png
<devilhorns> GrueMaster, but, look @ the button
<devilhorns> and looking @ the icon itself, you can see "the problem"
<GrueMaster> Yep.  Icons aren't centered in their frame.  Bad.
<devilhorns> yep :)
<devilhorns> now what kinda moron makes icons like that ... *sigh*
<ajay> rsalveti, is this happens due to any null modem cable error as well?
<GrueMaster> There's probably a patent if they did.
<rsalveti> ajay: could be, but generally you get tons of weird characters when getting garbage
<devilhorns> a patent for centering icons ? I highly doubt that :)
<rsalveti> ajay: are you open it with 115200?
<ajay> yes
<GrueMaster> Never know with software patents.
<ajay> hw and sw flow control is off
<rsalveti> generally I never use minicom, just screen /dev/ttyUSB0 115200 is enough for me
<devilhorns> GrueMaster, well, if that is the case, then every designer on the planet is in trouble :) I mean really, how Doesn't center images ? :)
<rsalveti> but could be cable issues also
<rsalveti> maybe wrong pins
<GrueMaster> heh
<ajay> rsalveti, i have checked i am using cross cable
<ajay> null modem
<ajay> IDC10 DB9 also as mentioned in websites
<ajay> rsalveti, for screen /dev/ttyUSB3 115200 also i am getting just blank screen
<rsalveti> ajay: any garbage?
<ajay> nothinmg
<ajay> if i write then it is getting garbage
<ajay> rsalveti, if i write same thing is getting printed
<rsalveti> hm
<ajay> just for enter key getting printed at start ï¿½
<devilhorns> GrueMaster, btw
<ajay> is it cable problem?
<ajay> or uboot xloader got corrupted
<devilhorns> that bug is not in une-efl ... it's a control-center (appearance properties) problem
<GrueMaster> That's what I thought when I filed it.
<rsalveti> ajay: could be, but it it was corrupted you should not get any echo from uart
<ajay> rsalveti, but not even getting uboot prompt
<ajay> or any message saying loading
<devilhorns> yea, the issue is that "appearance-properties" creates a "custom" theme whenever you change any "looks" (fonts, colors, etc). When it creates that "custom" theme, it takes the base theme, changes all the properties for it in gconf, then saves it. When it does the changes, it reads the values of the original theme (icons, colors, etc) and updates gconf values for that
<pcacjr__> ajay: are you doing that with sudo ?
<rsalveti> ajay: I would first suggest you to make sure you're using a valid x-loader and u-boot
<rsalveti> if I'm not wrong, there's a default one at the nand
<devilhorns> so modifying anything, resets all the gconf properties to default for that "base theme", and saves the custom values
<rsalveti> then checking if the cable and etc is correct
<devilhorns> so it's reseting "icon theme" to the default for that original theme
<ajay> pcacjr, i am doing with root
<ajay> rsalveti, how to make sure that i am using valid xloader or u-boot
<pcacjr__> rsalveti: should he at least get some weird bytes on the screen ?
<devilhorns> GrueMaster, @ any rate, I'm not going to "doctor" my code for badly designed icons :) the centering issue will remain just that. an "issue" because of bad icons :)
<GrueMaster> I wouldn't either.  File a bug on the icon set.
<rsalveti> ajay: getting the stock one, provided by the igep website
<rsalveti> pcacjr__: yup
<devilhorns> GrueMaster, indeed :) Will do that later when I have some time
<rsalveti> ajay: http://shop.igep.es/index.php?main_page=product_info&cPath=1&products_id=8&zenid=701aa01925001b84ed070559d8ac0851
<rsalveti> probably same one from beagle
<ajay> rsalveti, i have same one
<rsalveti> ajay: http://www.igep.es/index.php?option=com_content&view=article&id=99&Itemid=112&dir=/var/www/vhosts/igep.es/httpdocs/downloads/01-ISEE_Products/IGEPv2/SW_Releases/binaries
<ajay> rsalveti, shall i keep xloader and uboot in sdcard
<ajay> from above link
<rsalveti> yep, at least at beagle you can boot using the x-loader and u-boot from the sdcard by using the user button, don't know if we have the same for igepv2
<ajay> rsalveti, no there is no button for igep
<ajay> rsalveti, http://labs.igep.es/index.php/How_to_recover_a_IGEP_bricked_board
<ajay> this site is for showing to recover a board
<ajay> but not sure shall i follow these steps
<dcordes> bbl
<rsalveti> ajay: well, if you just follow these steps you'll for sure be able to flash a valid x-loader and u-boot, and get something at your uart
<rsalveti> if you set up your sd and still see garbage, than your problem could be related with your cable setup
<devilhorns> anyone running unity ?
<ajay> rsalveti, is this problem due to power cable also?
<rsalveti> ajay: just if you're not using the proper 5v one
<ogra_ac> bug 607752
<ubot2> Launchpad bug 607752 in ubuntu "[needs-packaging] devmem2 needs packaging (affects: 2) (heat: 59)" [Wishlist,New] https://launchpad.net/bugs/607752
<ogra_ac> hrm
<ajay> rsalveti, i tried above wiki of recovering brick igep board
<ajay> but for this also i am getting similar error as no messages
<ajay> if i press any key from keyboard hetting printed as ï¿½
<rsalveti> so probably an issue at your cable setup, or usb-serial converter
<lool> rsalveti: Plenty of people get this issue with IGEP
<lool> There is a hardware grounding issue I'm sure
<lool> one workaround is using a differnt USB serial adapter, or a real PC serial port; another workaround is plugging a mini-USB cable to the IGEP to help grounding
<rsalveti> lool: hm, interesting
<vgrade> hi guys, anyone working on i.MX51
<ogra_ac> amitk does
<vgrade> ogra_ac, thanks
<GrueMaster> rsalveti: Can you download http://ports.ubuntu.com/dists/maverick/main/installer-armel/20100211ubuntu28/images/omap/netboot/omap/* and try on your beagleXM?  I am seeing it either not detecting my USB keyboard or it is locking up hard.
<rsalveti> GrueMaster: sure
<GrueMaster> You will have to copy these to an existing image partition1 to get MLO & u-boot.bin
<rsalveti> sure, np
<rsalveti> GrueMaster: which image did you use as base?
<GrueMaster> RC
<GrueMaster> Or 20100929.
<rsalveti> OK, ping back you in some minutes
<GrueMaster> too bad u-boot for beagle doesn't support tftp.  Make my life much easier.
<ogra_ac> rsalveti, GLES packages uploaded
<ogra_ac> cross your fingers that the release team lets them in :)
<rsalveti> ogra_ac: cool, let's wait and see :-)
<rsalveti> ogra_ac: where can I track it?
<ogra_ac> i filed bug 652347
<ubot2> Launchpad bug 652347 in ubuntu "[needs-packaging] opengles-sgx-omap3 and powervr-omap3 need to be packaged for maverick (affects: 1) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/652347
 * ogra_ac hopes thats enough to justify the FFe 
<ogra_ac> rsalveti, some clear final statement for bug 607752 would be helpful btw
<ubot2> Launchpad bug 607752 in ubuntu "[needs-packaging] devmem2 needs packaging (affects: 2) (heat: 59)" [Wishlist,New] https://launchpad.net/bugs/607752
<rsalveti> yup, devmem2 is very useful but ugly
<ogra_ac> right
<ogra_ac> the discussion just doesnt end clearly with "we will use it"
<rsalveti> ok, will comment on it
<GrueMaster> rsalveti: I get the same results on the beagle & beagleXM with the netboot image.  complete lockup.
<rsalveti> weird, my image is just resizing, will test it when it finishes
<rsalveti> now creating swap...
<GrueMaster> resizing?
<GrueMaster> It should boot into the debian installer.
<rsalveti> yep, but I was going to test your kernel to see if it works or not
<GrueMaster> Make sure you are using the boot.scr, uImage and uInitrd from http://ports.ubuntu.com/dists/maverick/main/installer-armel/20100211ubuntu28/images/omap/netboot/omap/*
<rsalveti> I just flashed 20100929
<GrueMaster> Oh.
<rsalveti> yup, will use that
<GrueMaster> No need to go through the preinst boot stuff.
<rsalveti> I know, just wanted to at least have a proper rootfs
<rsalveti> ok, will use your kernel and initrd now
<GrueMaster> Why?  It creates one (or it is supposed to).
<GrueMaster> brb
<ogra_ac> rsalveti, the initrd contains the debian-installer
<ogra_ac> it will wipe your rootfs
<rsalveti> oh, ok, didn't know the debian-installer was inside it
<rsalveti> yep, so just booting it should be enough
<rsalveti> let me try
 * rsalveti used with the pre-installed image
<ogra_ac> the great thing is that the whole installer lives in ram
<ogra_ac> so you can do whatever you like to your disks
<ward|> whats the simplest way of getting a rootfs for my PXA272 based PDA ? i should be able to roll my own kernel
<ogra_ac> see /topic
<ogra_ac> ;)
<ward|> is that the simplest way?
<ward|> allready saw that
<rsalveti> GrueMaster: yup, no usb
<rsalveti> GrueMaster: probably missing modules...
<ogra_ac> rsalveti, yeah
<rsalveti> let me boot with uart
<ogra_ac> old re-occuring bug
<ward|> ogra, oh never mind, it cant get much simpler than that i see :p
<ogra_ac> ward|, yep :)
<rsalveti> no modules at all
<rsalveti> not good
<ward|> so together with a 2.6.x kernel this should work fine? is there a minimum version or something?
<ogra_ac> ward|, udev in ubuntu is usually tied closely to the kernel version
<ogra_ac> ward|, so you should make sure yu have something matching
<ward|> ogra, ah, so if i only got one specific kernel version i can compile, i should forget about it and use another distro?
<ogra_ac> which version do you have ?
<ward|> ogra, let me see
<ward|> ogra, 2.6.26
<ogra_ac> ugh
<ogra_ac> thats ancient
<ogra_ac> with luck you can use jaunty on that
<ogra_ac> but jaunty is EOL in a few weeks
<ward|> well its not really coneniant updatiung the kernel all the time on a closed source PDA lol
<ogra_ac> indeed
<GrueMaster> Ok, netboot for dove works.  Just finished.
<rsalveti> GrueMaster: so, no modules at your uInitrd
<GrueMaster> Well now.  That would be a bad thing.
<rsalveti> ndec: upstream kernel is activating the errata for arch_omap4: https://patchwork.kernel.org/patch/183142/
<rsalveti> so I believe it should be fine with it
<rsalveti> at least my board is still up and building after using the errata
<rsalveti> 20 hours, and 9 builds
<ndec> rsalveti: but my understanding is that this errata is not needed on es2.0, it's fixed in the arm chip in es2.0...
<ndec> rsalveti: but i might be wrong ;-)
<rsalveti> ndec: yep, thought the same but couldn't find anything about it =\
<rsalveti> GrueMaster: any idea why we're building the initrd without any modules?
<rsalveti> ogra: said that this is a re-occuring bug
<ogra> rsalveti, space
<GrueMaster> Nope.  Ask an engineer.  btw, meeting.
<rsalveti> yup
<ward|> ogra, i think i found out why the devs chose 2.6.26 lol
<ward|> ( ogra, provided you are ogra_ac)
<ogra> yes, i'm both on differnt devices in different rooms
<ward|> yeah just making sure :)
<ward|> the debian EABI docs use this version aswell, and they make it clear only that one is supposed to work: "NOTE: Take a lot of care, that _only this old linux kernel version works_."
<ward|> so maybe there are a lot more devices lie mine with this outdated kernel
<ward|> thought i should mention it so ubuntu-arm devs can investigate this if they want to
<robclark> ndec / rsalveti: which errata?
<rsalveti> robclark: PL310_ERRATA_588369
<robclark> ok.. let me check
<robclark> rsalveti: ok.. this one seems to apply to the cortex-a9 IP, prior to r2p0
<robclark> (just need to check which rev on cortex is in es2.0)
<robclark> r1p2.. so keep the errata enabled
<rsalveti> robclark: oh, cool, thanks for identifying it
<robclark> rsalveti: btw, was there any new discoveries on highmem in last couple days?
<rsalveti> robbiew: well, we were first trying to debug the issue without highmem, because we always face problems when using highmem
<rsalveti> with one cpu, without l2
<rsalveti> so then I found that we were not using this errata yesterday
<robclark> oh, ok.. so same sort of issue even without highmem?
<robclark> so w/ PL310 errata patch, it is getting more stable?
<rsalveti> gave it a try and I'm running without highmem, 2g:2g, 1gb, 2cpus and doing well
<robclark> ok.. that sounds like an improvement
<rsalveti> robclark: more than 20 hours building
<robclark> have you tried w/ highmem yet?
<rsalveti> no issues
<rsalveti> robclark: yup, and still get the issue easily, so probably another bug
<robclark> and that is also w/ the nvidia highmem patch?
<rsalveti> robclark: yup
<robclark> hmm.. ok.. so still another issue lurking :-(
<rsalveti> yeah :-( but at least we have a workaround to use 1gb now
<robclark> yeah.. I think 2g/2g is way to go for now
<rsalveti> and the build is now taking less than 2 hours
<rsalveti> using an external usb disk
<robclark> ohh..  we tried a USB drive at the last sprint, although I think it was quite a slow usb powered hd..
<GrueMaster> That and it was all ES1 then, wasn't it?
<rsalveti> probably, and using usb otg
<GrueMaster> rsalveti: Can you confirm Bug #652522?  Thanks
<ubot2> Launchpad bug 652522 in debian-installer (Ubuntu) "modules missing from omap netboot image. (affects: 1) (heat: 8)" [Medium,New] https://launchpad.net/bugs/652522
<rsalveti> GrueMaster: sure
#ubuntu-arm 2010-10-01
<persia> gourneau, The Netwalker V2 might also meet your needs: 5" tablet, ships with 9.04, USB host, etc.
 * rsalveti brb
<cwillu_at_work> persia, link?
<persia> http://www.sharp.co.jp/netwalker/pct1/index.html
<persia> http://www.sharp.co.jp/netwalker/pct1/spec/index.html might be more useful for some folk :)
<cwillu_at_work> no english page?
<persia> Not from Sharp
 * persia looks for a reseller
<persia> http://shop.conics.net/index.php/computers/pda-mid/sharp-netwalker-pc-t1-b.html
<persia> (also available in Silver)
<cwillu_at_work> http://www.alwaysinnovating.com/products/touchbook.htm seems more useful
<cwillu_at_work> I'm a sucker for a physical keyboard :p
<persia> cwillu, I also, which is why I got one of http://shop.conics.net/index.php/computers/pda-mid/sharp-netwalker-white.html :)
<persia> touchbook is too big and heavy to be exciting for me (although it works nice, and I've seen a few folk very happy with them)
<persia> but gourneau was looking for something like the SmartQ7, and the SmartQ7 can't run modern Ubuntu.
<persia> In the with-physical-keyboard-but-oversized-for-persia arena, there is also http://www.genesi-usa.com/products/smartbook : I know some Genesi stuff ships with Maverick, but don't know anyone who purchased one of these yet.
<persia> (and, so, I have no special affinity for i.MX51x based designs: they just happen to be widely available with little waiting today)
<persia> s/so/no/
<davidm> persia, lucid not Maverick
<persia> davidm, The Efika Smartbook ships only with Lucid?  The Maverick shipments I heard about were EfikaMXs
<persia> Or maybe that's just stuff from the developer program.
<davidm> I was thinking of the Genesi stuff
<davidm> If its Maverick it's not something we have done as we do not have a kernel that works with maverick
<persia> Nobody is shipping our kernels today, except us.  All of Touchbook / Smartbook / Netwalker require custom kernels, sadly.
<davidm> The iMX51 kernel was already a release behind on lucid
<persia> I think Genesi has a maverick imx51 private kernel
<davidm> and Freescale does not have one new enough
<lool> There's a maverick image download for the efikamxes
<persia> Ah, hrm.  Could be old.
<davidm> They would have had to forward port "a lot" of stuff
<persia> lool, Do you have a link, or know the kernel version offhand?
<lool> bottom of http://www.powerdeveloper.org/platforms/efikamx/linux
<lool> Their kernels are on gitorious
<lool> http://www.gitorious.org/efikamx/linux-efikamx
<lool> there's a -kernel for the smartbooks as well
<persia> Sorry for confusion, by "internal" I meant "specific to that board and not in Ubuntu"
<lool> it's 2.6.31 based though
<davidm> will be interesting what kernel they shoehorned in
<davidm> Ah so it is a lucid kernel
<persia> OK.  2.6.31 is a bit aging, but with enough sauce, I suspect it could work just fine.  It has the new input stuff.
<persia> lool, Do you know if the linaro imx51 tree supports the Genesi or Sharp products?
<rsalveti> cooloney: hey, just sent one email saying that I didn't get any issues while testing current kernel
<rsalveti> and nice that the patch was easily merged, and we got a new version already
<cooloney> rsalveti: thank you so much for testing.
<rsalveti> np
<cooloney> rsalveti: helped a lot. I am going to verify the auido patches, then send out the pull request
<cooloney> rsalveti: so far did you meet any audio issue with the audio fix
<rsalveti> now the next step is to activate 1gb at the pre-installed image, and let more people test it
<cooloney> rsalveti: agree, ogra will help to activate that mem=1G in U-Boot boot args, i guess
<rsalveti> using the kernel built from my tree (with the audio patches) and using the config files from bug 637947 I was able to listen a couple of mp3 without any issues
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/637947
<rsalveti> but testing with hdmi
<rsalveti> needs more testing, but it seems that's working at least
<persia> rsalveti, Which config files did you use from the bug?
<cooloney> rsalveti: i never tried auido over hdmi before. need any special cable convert?
<rsalveti> persia: with latest tree you can use SDP4430.conf that berco added today at the bug report
<rsalveti> and then it seems we still need to change pulse to use it
<cooloney> rsalveti: oh i just connect a speaker to the board, then sound's out
<cooloney> that's my plan
<rsalveti> cooloney: cool, I don't have a speaker around, so I tested with my tv
<rsalveti> persia: I didn't follow all the audio discussions we had last week, but how are we planning to fix the need of changing the pulse audio config file?
<cooloney> rsalveti: you got expensive equiment, heh
 * cooloney brb, lunch time
<persia> rsalveti, Which pulse files did you change from default?
<rsalveti> persia: /etc/pulse/default.pa
<rsalveti> persia: is expected that the alsa config file be enough to get it working with pulse?
<persia> No.
<rsalveti> ok
<persia> Just to confirm, the changes you made to default.pa were to disable module-udev-detect and to add some load-module calls?  Did you have to change it any other way?
<rsalveti> did the same change ogra did at https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/14
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 14)" [High,Confirmed]
<rsalveti> so how are we going to proceed with the relase?
<persia> OK.  That's not as bad as it used to be.  If you don't do this, does it just not work at all, or only partially work?
<rsalveti> the alsa conf is fine, we can create a package for it and deploy it at the TI ppa, or even setting up at jasper in the worse case
<rsalveti> that's what I'm going to check now
<rsalveti> just tested following the procedure to be sure the kernel was working
<rsalveti> as mpoirier was working at these issues
<persia> Last I understood with the investigation of this was that we didn't have the module loading stuff we needed from udev, and udev didn't have enough information in /sys to provide it.
<persia> No worries.  We can figure out what is missing :)
<rsalveti> ok, I'm just installing the latest pre-installed image and will check this
<persia> Wow!  I would have expected yo u to just revert the default.pa changes or reinstall pulse, forcing config overwrite.
<rsalveti> nops, that sd card is invalid atm :-)
<rsalveti> many tests and debugging happening during the day ;-)
<rsalveti> but panda is fast, so I'm fine
<rsalveti> persia: ok, just changed the alsa file
<rsalveti> still got [  123.889129] asoc: no valid backend routes for PCM: SDP4430 Media
<rsalveti> let me test aplay now
<persia> That message is the kernel not knowing how to deal with the audio path: either the driver needs touching, or the config needs more work.  Hard to say which is correct.
<rsalveti> hm, no hardware at audio menu
<persia> OK.  Anything from pulse in syslog or .xsession-errors?
<rsalveti> aplay gives main:654: audio open error
<rsalveti> let me check
<persia> What!
<persia> If aplay has an error, then ALSA is broken.
<rsalveti> could be an invalid entry at the config file
<rsalveti> http://launchpadlibrarian.net/56799615/SDP4430.conf
<persia> You're running with a kernel with the patches applied?
<rsalveti> hm, doesn't seems that it loaded the config file
<rsalveti> at least alsamixer is not showing the same thing
<rsalveti> same volumes and etc
<rsalveti> persia: yup
<persia> Well, that doesn't sound "fixed" :)
<rsalveti> getting  0 [SDP4430        ]: SDP4430 - SDP4430 from /proc/asound/cards
<persia> How was it when it worked for you?
<rsalveti> using https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/+attachment/1583666/+files/omap4_amixer_config.sh
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 14)" [High,Confirmed]
<rsalveti> and the pulse change I said before
<rsalveti> but I remember the changed berco|laptop did was to be able to load the config file automatically during boot
<rsalveti> while recognizing the board name
<persia> Which involved some kernel changes.
<rsalveti> yup
<rsalveti> persia: ok, removed the old alsa.state, rebooted and now I don't get this error at aplay
<rsalveti> probably old config hanging around
<persia> OK.
<rsalveti> but still no sound...
<rsalveti> still seems that it didn't load the config file
<persia> So aplay still doesn't work?
<rsalveti> doesn't give any error, but no sound, but probably explained by the lack of correct values at the mixer
<rsalveti> volume and etc
<persia> Which is supposed to be fixed by that config file
<rsalveti> yup
<rsalveti> persia: do you know how it should request and load the config file?
<rsalveti> at least to have something to start the debugging
<rsalveti> ok, alsactl should give me some hints
<rsalveti> alsactl init gives me: Found hardware: "SDP4430" "" "" "" ""
<rsalveti> but seems to be loading just the default alsa settings
<persia> rsalveti, Sorry, I don't really.  Fiddling with alsactl is about the most I can do.  GrueMaster may know more.
<rsalveti> persia: but I'm able to play with aplay -Dplughw:0,7 /usr/share/sounds/speech-dispatcher/test.wav, at the hdmi
<rsalveti> then how to tell the routes to pulse?
<rsalveti> without messing up with the config file
<rsalveti> well, more testing tomorrow, time to get some sleep now
 * rsalveti out
<persia> Good night :)  Anyway, the way to tell pulse how to work is for udev to populate the right audio paths, and have the right stuff in /sys.  I'll dig all that up, and prepare something that lets us test that for you and Gruemaster to play with when day gets there.
<hrw> morgen
<persia> Feeling particularly locale-bound today? :)
<lool> persia: No, the Sharp and Genesi products aren't supported in upstream or in Linaro trees
<hrw> persia: no, just from time to time I change
<amitk> persia: if you care to compile your own kernel, try the patches in my tree on git.linaro.org for genesi (and I suspect Sharp too)
<amitk> I'm working hard to get the basics all working for the next kernel merge window
<jo-erlend> If I wanted to install the preinstall on a harddisk, is there anything different I need to do, or would the approach be the same?
<ogra> bug 652873
<ubot2> Launchpad bug 652873 in hdparm (Ubuntu) "after installing hdparm, panda board fails to boot (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/652873
<persia> amitk, I'll try on a Netwalker just after release.  That sounds extra promising.  Thanks.
<Kamondelious> is the rtl8192su driver support ported already in 10.04 or 10.10?
<Kamondelious> I've been googling and can't find an answer =(
<amitk> persia: I'm not targeting it to ubuntu/linaro release. If I get it upstream in the next couple of weeks, I might ask for it to be pulled into linaro.
<persia> amitk, It's not your target: it's my time and available hardware :)
<persia> I'm not likely to have sufficient armel build-time to build a kernel until release, and am even more unlikely to have time to build a custom Netwalker boot SD.
<gourneau> I am getting a SmartQ V7.  It is said to have Ubuntu on it.  Does anyone know anything about those?
<rsalveti> jo-erlend: if possible, can you test bug 646368?
<ubot2> Launchpad bug 646368 in linux (Ubuntu) "smsc911x has no module alias, does not get auto-loaded on OMAP3 EVM (affects: 1) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/646368
<rsalveti> I created a kernel deb that has the proper patch to make the module autoload correctly
<rsalveti> as I don't have an igepv2 I can't test it
 * rsalveti out for lunch
<rsalveti> argh, using 3g now, having issues with my internet provider
<GrueMaster> fun
* You're now known as ubuntulog
<txwikinger> is there already a good and free IDE that I can use for the lpc1343 arm chip on (K)ubuntu?
<GrueMaster> Not something that this group really focuses on.  This forum mainly focuses on ubuntu running on Cortex A8/9 based systems.
<ogra_ac> and why would you run an IDE on your arm device ?
<ogra_ac> :)
<bfarrow> txwikinger: I doubt that there is a pre-packaged IDE, but if it uses a gcc crosscompiler then you can probably use eclipse or kdevelop.
<txwikinger> the crosscompiler is only available for maverick, correct?
<txwikinger> kdevelop is ok
<devilhorns> or codelite, or codeblocks
<devilhorns> (if you don't want the java bloat of eclipse, or qt bloat of kdevelop) :)
<bfarrow> txwikinger: and you should be able to use gdbserver if your target is running linux or gdb stubs if the target has no OS
<txwikinger> well.. the lpc1343 is too small to run linux I would think
<txwikinger> only has 32k flash and 8k ram
<txwikinger> The whole thing is for a hackerspace conference
<bfarrow> txwikinger: if the ide uses gdb then you can usually get it to use the cross gdb and debug over a serial line to gdb stubs
<txwikinger> The name badges that are given out are special prototype pcbs
<txwikinger> I will be giving a presentation and would like to offer in that presentation a free toolchain/IDE that works on Ubuntu
<bfarrow> txwikinger: do you have a serial port on it ?
<txwikinger> Yes, a usb port
<bfarrow> txwikinger: hmm, I don't know hard it would be to get gdb stubs to use USB.  Can you get to the UART signals from the lpc1343 ?
<txwikinger> yes.. you can do that too
<txwikinger> we have the pins layed out to be used
<bfarrow> txwikinger: Hmm, I will have to give codelite a go, it looks like it can use an external cross gdb.
<devilhorns> :) it's not bad if you like IDEs
<devilhorns> personally, I just use jed + rxvt-unicode :)
<ogra_ac> vi FTW :)
<devilhorns> ewwww
<bfarrow> I tend to use vi and gdb command line due to the lack of a good and fast IDE
<devilhorns> I'll never understand people's obsession with an editor that requires you to use a bunch of archaic and cryptic key strokes todo even the simpliest things :)
<GrueMaster> What do you use?
<devilhorns> personally, I just use jed + rxvt-unicode :)
<ogra_ac> if i'd use jed my code would be scattered with :q
<ogra_ac> :)
<ogra_ac> like my OO.o docs are
<devilhorns> lmao
<devilhorns> :q some kind of weird smiley ? or one of those cryptic vi commands ?
<bfarrow> at least I haven't configured my shell to use vi key-commands
<ogra_ac> finger memory ;)
<ogra_ac> devilhorns, the quit command
<devilhorns> ogra_ac, aahhh
<ogra_ac> :w is also one i use often
<txwikinger> Well. I am fine with commanline and editor too
<devilhorns> see, that's another reason I like jed ... can also use the menus, so no need to remember cryptic key strokes :)
<txwikinger> but there are those annoying people who call themselves users :D
<devilhorns> txwikinger, blah, losers :P
<txwikinger> Well... I want to see some happy faces when I do my presentation
<devilhorns> well that's easy
<ogra_ac> give out drugs at the entrance ?
<txwikinger> maybe I should use quickly or quick-qt and create an IDE during my presentation :)
<devilhorns> tell them all they are gonna get laid :P
<txwikinger> oh well.. there goes the PG rating
<devilhorns> lol
<robclark> rsalveti: is there some trick to make your deb-pkg trick for cross compiling kernel play nicely with dkms?
<robclark> I ended up getting dkms to build the modules ok (for sgx and tiwlan).. by NFS mounting my original kernel srcs directory under /lib/modules/.../source
<robclark> but somehow vermagic is wrong in the resulting modules.. still using the old kernel's vermagic
<ndec> robclark: rsalveti i am interested in the solution too ;-)
<rsalveti> robclark: ndec: hm, never tried this kernel with dkms
<rsalveti> probably missing the headers package
<rsalveti> could be that dkms is building with omap4 headers
<rsalveti> instead of yours
<robclark> hmm, yeah..  I had to create a symlink for the headers.. if that is where it gets vermagic, that would explain
<robclark> any convenient way to get a headers .deb too.. or you just manually copy over?
<ndec> rsalveti: it's a bit more than that in fact. there are some tools that are built when building the kernel. when cross compiling these tools are built for x86, and they are embedded in the .deb. when building the module natively with dkms, it fails since the tools won't work on arm
<rsalveti> ndec: yep, saw your email at the kernel-team ml
<rsalveti> it seems we don't have an entry for kernel-headers similar with deb-pkg
<rsalveti> ndec: did you try cross-compiling the ubuntu kernel?
<ndec> rsalveti: yes, we do that quite often in fact.
<rsalveti> but using dpkg-buildpackage?
<rsalveti> using the latest changes from rtg
 * robclark was just trying to build the old fashioned way..
<ndec> rsalveti: robclark: this: CROSS_COMPILE=arm-none-linux-gnueabi- skipabi=true skipmodule=true fakeroot debian/rules binary-omap4, would create the kernel and headers .deb files (with codesourcery)
<ndec> that should work with the new maverick cross compiler if you change CROSS_COMPILE
<rsalveti> ndec: yup, and did it work with dkms?
<ndec> rsalveti: nope... that's why I sent the email to andy ;-)
<ndec> or tim, i think.
<robclark> ndec: No rule to make target 'fakeroot'
<rsalveti> oh, so it's not just a theory, it's actually a proved problem
<robclark> (this is kernel-ubuntu.git from d.oz.o)
<rsalveti> fakeroot debian/rules clean
<ndec> robclark: I think you added an extra make in front no?
<ndec> robclark: just copy/paste the command above
<robclark> ahh, yeah
<robclark> gotcha
<ndec> robclark: and apt-get install fakeroot, if you don't have it
<robclark> already got it
<ndec> robclark: we are down to a few minutes for a full cross build on 8-core machine.
<rsalveti> ouch
<rsalveti> :-)
<robclark> ndec: make: *** No rule to make target `binary-omap4'.  Stop.
<rsalveti> robclark: try cleaning it, using the command I sent
<robclark> k
<robclark> same
<robclark> no worries.. it seems like it would be easier for now just to manually copy over headers
<rsalveti> weird, works fine for me...
<rsalveti> binary-omap for omap 3 kernel and binary-omap4 for omap 4
<rsalveti> but the omap 3 just works if you're using our main kernel tree
<robclark> hmm.. I'm using kernel-ubuntu.git tree on dev.omapzoom.org.. the for-ubuntu-2.6.35 branch..
<ndec> robclark: this is the right kernel, this is our branch that gets merged in ubuntu official kernel later.
<robclark> yeah.. so I figure it has all the appropriate magic..
<robclark> hmm, ndec, I'm a bit confused about how your command is supposed to work...
<robclark> grep -r binary-omap4 debian
<robclark> nothing
<robclark> maybe I am on wrong branch?
<ogra_ac> robclark, how do you build ?
<ogra_ac> is it a package ?
<robclark> well.. in the past I never built kernel package.. I'd just build manually, copy uImage to my MMC card, and away I go
<ogra_ac> what counts in a package is the actual dependency in the control file
<ndec> robclark: grep -r 'binary-' debian
<dcordes> ogra_ac: ok it really was file corruption
<robclark> hmm.. well..  actually, I'm really just looking for the easiest way to rebuild a kernel now that I'm using the initrd stuff, and ubuntu kernel which makes a lot more stuff modules (and sgx and stuff)
<ndec> robclark: the easiest one is native compilation ;-) so I think you are in fact looking for the fastest one ...
<robclark> ndec: yeah.. I guess fastest is a better word..
<robclark> ndec: http://pastebin.com/DbXyMDWy
<robclark> (yeah, IT stopped blocking pastebin!)
<dcordes> RC working fine now
<ogra_ac> dcordes, ah, i was just wondering what you refer to in the above conversation :)
<ndec> robclark: oops. you need to run this first: export $(dpkg-architecture -aarmel)
<robclark> ahh.. ok.. let's try that
<rsalveti> robclark: do you have a directory called debian.ti-omap4?
<robclark> rsalveti: yup
<rsalveti> so fakeroot debian/rules clean should work and set up your env
<robclark> ok.. the extra export cmd that ndec gave seems to have done the trick
<ndec> robclark: yes, we need it too
<rsalveti> robclark: makes sense, otherwise you're going to build the kernel following your host arch
<robclark> ahhh.. yeah, I could see how that would be a problem
<robclark> oh.. doh.. it forces me to mrproper.. which nukes my .config..
<rsalveti> robclark: yup, it'll get the config file from the package
<rsalveti> you can copy yours to debian.ti-omap4/config/config.common.ubuntu
<rsalveti> before buildint it
<robclark> ahh.. ok.. cool
<dcordes> tmzt_: how do you rotate the screen in rhobuntu ?
<dcordes> tmzt_: xrandr ?
<tmzt_> no, add Option "CW" to xorg.conf under the device
<tmzt_> Option "Rotate" "CW"
<tmzt_> you aren't using codeaurora driver?
<tmzt_> you're using fbdev?
<dcordes> tmzt_: I am using xf86-video-fbdev , yes
<dcordes> tmzt_: I compiled xf86-video-msm from codeaurora but the msm_fb in the kernel I use does not match so I will get corruption
<tmzt_> Section "Device" Identifier      "fbdev" Driver          "fbdev" Option  "Rotate" "CW"
<tmzt_> EndSection
<dcordes> xrandr does not work in rhobuntu ?
<dcordes> btw, what is rhobuntu ? karmic ?
<robclark> rsalveti, ndec:  well, not quite all the way.. but further.. http://pastebin.com/Q49QvW50
<robclark> is our tree missing debian/control?
<rsalveti> robclark: gets generated by running clean
<robclark> hmm.. ok.. so I should have followed your instructions the first time ;-)
<ndec> sounds like a good starting point!
 * robclark is just impatient sometimes
<dcordes> In the latest netbook rootfilesystems the gnome-panel is locked so that one cannot move or remove applets. I checked gconf-editor on it and there is the /apps/panel/global/locked_down bool
<dcordes> It is not set to true so it doesn't seem to affect it
<orbarron> hey guy I need a toll to test a touch screen on ubuntu
<orbarron> err toll = tool
<dcordes> orbarron: multi touch ?
<dcordes> So the qustion is, how can I unlock the gnome-panel in netbook ?
<orbarron> no.. thought I try touchscreen calibrate
<dcordes> do you use evdev or tslib ?
<dcordes> evtest or ts_test
<prpplague> dcordes: it's an event interface
<orbarron> no... but I need something to calibrate
<dcordes> orbarron: ts_calibrate
<persia> gourneau, If you want to use Ubuntu on it, I recommend against the SmartQ7: the processor in it can only run Ubuntu 9.04 (which ceases support in a couple weeks).
<persia> gourneau, The closest I know to be available in form-factor that can run current Ubuntu is the Sharp Netwalker tablet (available widely retail in Japan, or from exporters (conics.net and others)
<orbarron> ahh can't get ts_calibrate...
#ubuntu-arm 2010-10-02
<dcordes> These instructions can be used to work around the locked panel: https://help.ubuntu.com/community/UbuntuNetbookEdition/ConvertGnomeSession
<dcordes> It will add une-efl to the gnome session
<ogra_ac> dcordes, totally wrong for maverick though
<ogra_ac> (and breaks the gnome session)
<dcordes> ogra_ac: ok what is right for maverick ?
<dcordes> I think it is difficult to close windows with the maximus concept
<ajay> hi all, i have connected usb to serial connector ,i need to connect cross null modem female to female cable so i chave connected female to male cross null modem cable
<ajay> to which i connected straight female to female null modem cable
<ajay> to this i connected DB9 to IDC 10 cable
<ajay> does cable length affects for minicom
<ajay> due this connection cable length got incresde
<ajay> increased
<rsalveti> ajay: hey, don't know if you saw what lool wrote about serial and igepv2
<rsalveti> seems to be a common issue
<rsalveti> <lool>  rsalveti: Plenty of people get this issue with IGEP
<rsalveti> <lool>  There is a hardware grounding issue I'm sure
<rsalveti> <lool>  one workaround is using a differnt USB serial adapter, or a real PC serial port; another workaround is plugging a mini-USB cable to the IGEP to help grounding
<rsalveti> ajay: ^
<ajay> rsalveti, thanks but i have tested with different serial adapter getting same issue and other is mini USB ,can you please tell how to solve grounding problem
<rsalveti> ajay: if you have a mini-usb cable, you could connect it at igepv2 and your pc
<rsalveti> that should help fixing the grounding issue
<ajay> rsalveti, i need to get a mini USB cable for this
<ajay> mini USB need to connect to pc USB port correct?
<ajay> i mean mini USB port to igep and other port to PC USB port
<rsalveti> ajay: yep
<ajay> rsalveti,if i connect hdmi  cable to board then i am getting just blank screen it means board is somewhat booting till uboot
<ajay> am i right?
<rsalveti> not sure
<ajay> rsalveti, if i change omapfb parameter for boot.ini file then different behaviour shows that is some time signal is not proper
<rsalveti> hm, ok, so it seems your kernel is booting
<ajay> rsalveti, yes but i am not getting any display on monitor so thought to chech in minicom but there also i am not getting message
<ajay> may be as you told grounding issue
<ajay> rsalveti, is there any way to debug using ethernet port?
<ajay> i mean using PC to PC cable
<rsalveti> you first need a working kernel
<ajay> rsalveti, that i have downloaded from their website
<ajay> a binary image
<ajay> rsalveti, i am followed steps for ubuntu 10.10 as mentioned http://labs.igep.es/index.php/How_to_get_the_Ubuntu_distribution
<ajay> using wget downloaded image and then created boot.ini and removed MLO,uboot.bin boot.scr from /booot
<ajay> and connected minicom and then did power on but with this also i am not getting any message over minicom
<ajay> surely something is wrong in my board or setup
<ajay> minicom i have setup as per wiki mentioned for minicom8N1 115200
<ajay>  rsalveti i  got a mini A USB cable but as you suggested i connected mini A port to igep board where do i need to connect other port of Mini A USB cable
<ajay> rsalveti, for solving grounding issue
<dcordes> go home button messes up onboard: it hides onboard itself along with the floating 'show onboard button' that should be always on top
#ubuntu-arm 2010-10-03
<devilhorns> grrr
<ajay> hi all, i was going through igep forum , isaw Remove from IDC cable the pin 6 or remove all cables except pin 2,3 and 5, that's all.
<ajay> Don't remove the protection resistors if you don't know what are you doing, if you remove the resistors and connect directly a full RS232 to J960 you can damage the board.  is the solution for grounding issue
<ajay> so should i remove DB9 connectors all pin other than 2 3 5
<ajay> where this resistor resides in IDC10 to DB9 cable
<ajay> which absence can cause damage of board
<dcordes> I am wondering if this a netbooklauncher or an onboard bug: onboard and onboard floating maximize button are both hidden when the 'go home' gnome-panel-applet button is pressed
<dcordes> Any advise welcome.
<persia> dcordes, Might try asking in #ubuntu-bugs: the folk there tend to be very good at hunting down the appropriate package.
<dcordes> Few weeks ago I came here pestering everybody about folowing problem:
<dcordes> In any ubuntu arm rootfs networking would only work as root
<dcordes> non privileged users were unable to ping or use network in any other way
<dcordes> solution is fairly easy
<dcordes> # CONFIG_ANDROID_PARANOID_NETWORK is not set
<ynezz> lol?
<dcordes> ynezz: it is for potential log readers.
<dcordes> If you put question somewhere and find solution it is good to put it in the same place
<ynezz> ok, I just don't get that config directive, that's all
 * persia thinks the easier way is not to start from an Android kernel :)
<dcordes> persia: There are no options
<dcordes> persia: I had to patch many drivers in order for stuff to work
<dcordes> ynezz: if you set that config only root will be able to use network. I think the android javablob is executed as root .. and some strange abstraction on top of that
<dcordes> for permissions
<ynezz> dcordes: and you're porting android kernel to ubuntu, or what's the use case?
<dcordes> ynezz: I am patching the android kernel so it will work with any GNU/Linux userspace
<ynezz> ah
<dcordes> Hm would this be a good idea to inquire about Xorg input device problem in maverick RC ?
#ubuntu-arm 2011-09-26
<i-node> helo
<i-node> hello*
<twb> Does qemu-system-arm work *at all* on lucid?
<twb> Hm, same behaviour on sid
<twb> I give up, qemu-system-arm won't work for me on lucid, and the only non-lucid host I have, is a shitty little Atom netbook (where it works, but unbearably slowly)
<twb> I will just reflash the TF101 again with ubuntu so that I have something to actually do compiles on
<MMlosh> Grr..  the Oneiric kernel froze again..  (pandaboard with 2 DVB-T tuners atached)
<Daviey> janimo: Hey!  Can you confirm the bump is correct on linux-ac100?
<Daviey> New package: linux-ac100 (universe) [2.6.38-1.3 â 2.6.38-1000.1]
<janimo> Daviey, yes
<Daviey> janimo: What is the reasoning?
<janimo> I am about to upload the linux-meta-ac100 so it is in universe by tomorrow
<janimo> Daviey, I started with a new packaing using git
<janimo> and followed a tutorial and existing ubuntu/linaro numbering convention
<janimo> probably not needed in this case but I played it safe
<Daviey> janimo: I don't follow?  Where does it state jump to 1000?
<janimo> being my first time packaging a kernel by lots of trial and error eve
<janimo> Daviey, it doe snot, the linaro template I started with uses 1000.0
<janimo> and all linaro kernels use such large abi numbers afaik
<janimo> omap 1200, landing team ones 1400 etc
<Daviey> seems odd, but ok
<Daviey> infinity: ^^
<janimo> Daviey, tbh it seemed odd to me too, but if I were to question or dig into everything that seems odd to me in kernel packaging it would take me a lot more to get something ready
<janimo> not one of the tutorials were 100% correct or covered the various cases, jcrigby's one is the closest and best yet
<janimo> Daviey, at leats this package is now maintained in git and more or less in sync with how the kernel team and linaro manage their kernels
<infinity> That works for me.
<Daviey> janimo: heh, it's a black art that i don't understand either... The changelog generation blows me :)
<janimo> I even plan to upload it to the kernel repos so it is not only on my disk
<janimo> Daviey, I thought I understood everything about the changelog, when an innocent change in it (well version number addition _before_ the last one) tripped the ABI checker
<infinity> Would it surprise you to know that most of the kernel team doesn't know how the packages are built either? ;)
<infinity> A lot of that stuff is from BenC and I fiddling years ago.
<janimo> at which point I deferred work to next morning being an unexpected error after I thought I had ironed out all issues and built the package a few times already
<janimo> so I try to touch as little as possible
<infinity> The fact that it's survived is a testament to opaque code that no one wants to touch.
<Daviey> heh
<janimo> and learn more as I upload new revisions
<janimo> infinity, that would not surprise me in the least actually
<infinity> janimo: To fully understand it, you have to first understand Ben Collins.  After rooming with him at many conferences, I don't recommend it.
<janimo> and also it does not scale well
<janimo> would need many many conferences or very large rooms
<infinity> (That's not to say that I have anything against the guy, we're great friends, just warning that insanity may ensue)
<Daviey> infinity: I think you might want to room with lag.
<infinity> I don't need to corrupt any more Canonical employees, past, future, or present.
<infinity> For the good of the company, I should probably always room alone. :P
<Daviey> heh
<janimo> infinity, how selfless, you are.
<Daviey> infinity: I was more worried he'd corrupt you. :)
<infinity> Seems unlikely.
<infinity> But I'm always willing to be surprised.
<infinity> jcrigby: LINARO: always build debug packages
<infinity> jcrigby: ^-- From your recent uploads.  Don't we have that turned off for distro kernels (to avoid duplication of massive packages between -dbg and .ddeb)?
<jcrigby> crap
<jcrigby> that was a change for linaro ppa
<infinity> I figured.
<jcrigby> because we wanted the debug stuff
<jcrigby> infinity, ok educate me
<infinity> Because PPAs don't do ddebs, yes.  Longstanding feature request for that in LP. :P
<jcrigby> so my fix didn't fix because it still goes to ddeb
<jcrigby> it just always does it
<infinity> Oh, in which case, these are fine for the primary archive. ;)
<jcrigby> right
<infinity> And you still need a better fix for your PPA, I guess.
<jcrigby> so two wrongs make a right
<jcrigby> yes, I need to not do the rename to ddeb
<jcrigby> in ppa
<jcrigby> so the debug stuff will just stick around like a normal deb
<infinity> You can cheat and use archive_purpose to conditionally rename.
<infinity> I'm a bit shocked the default templates don't do that.
<jcrigby> you can tell me what the current stuff does
<jcrigby> it looks in / for some file
<jcrigby> let me look
<infinity>  /CurrentlyBuilding
<jcrigby> yes
<jcrigby> and uses that to decide if it is a local developer build or an archive build
<jcrigby> if that file exists it sets fullbuild or somesuch
<infinity> Kay, but if you check the value of it, you can get more in-depth.
<jcrigby> then later do_debug get set or not based on full_build
<janimo> infinity, jcrigby a meta package should just need a changelog bump and debian/rules will DTRT on build?
<infinity> janimo: Depends on the meta source.  But that's how most work.
<janimo> ok, this is ogra's ac100 meta. Should work as it has no magic besides the debian/ dir in it
<infinity> jcrigby: You can see in build logs that Purpose is actually set to a value in that file.
<jcrigby> ok so packages are ok except for crappy short changelog
<infinity> jcrigby: (Check the sbuild call for '--purpose='
<infinity> jcrigby: For instance for primary archive, it's --purpose=PRIMARY
<jcrigby> ahh
<janimo> infinity, linux-meta-ac100 uploaded, fingers crossed, etc
<infinity> jcrigby: For PPAs, it should be PPA, but double-check one of your build logs. :P
<jcrigby> wow, I need to hang out with infinity for a week of intense training
<jcrigby> ok, I'll do that
<jcrigby> infinity, is this documented anywhere?
<jcrigby> or just in package masters heads?
<infinity> jcrigby: *mumbles something about the launchpad source code*
<jcrigby> :)
<infinity> jcrigby: I'd be willing to bet that about 5 people know how this works, and 2 don't work here anymore.
<infinity> jcrigby / janimo : Kernels all accepted, after some very generous review.  May $diety have mercy on your souls if they all break. :P
 * infinity really goes to find food this time.
<janimo> infinity, thanks
<infinity> jcrigby: Even for subarches like this where we're not building official images, it would be swell if, next cycle, you keep slightly more in sync.  Diffs that large a 2 weeks before RC are a bit scary.
<infinity> s/a 2/2/
<jcrigby> I agree
<jcrigby> I need to make the ubuntu upload part of my normal workflow even though we (linaro) consume kernels from ppa
<infinity> Certainly until we hit kernel freeze, anyway.
<infinity> Then you need to get picky and potentially fork.
<jcrigby> infinity, are you back from lunch
<jcrigby> ?
<infinity> jcrigby: I keep forgetting to start lunch.
<infinity> jcrigby: 'sup?
<jcrigby> so did I understand that I can look inside /currentlywhatever to figure out if I am ppa or normal or ...
<infinity> jcrigby: Yup.
<infinity> jcrigby: "Purpose: PPA" or "Purpose: PRIMARY" for PPA versus primary archive.  There are a few other possible values (PARTNER, etc), but those are probably the only two you care about.
<infinity> jcrigby: And no /CurrentlyBuilding at all can generally be assumed to be "user machine, or non-LP buildd".
<jcrigby> ok those two are all I need, thanks
<jcrigby> right
<jcrigby> thanks, I now need to go fix debug for ppa again
<jcrigby> but conditionaly so i don't break primary
<infinity> If and when we get around to merging the archive sbuild and the buildd sbuild, this might become more easily testable.
<jcrigby> sure
<infinity> And someone should probably hack up some CurrentlyBuilding support into pbuilder for similar "pretend I'm a buildd" testing reasons.
<Daviey> infinity: I started doing that for sbuild
<infinity> The upshot of that is that it would de-facto document it all.
<infinity> Daviey: You're not the only one. :P
<Daviey> infinity: CurrentlyBuilding support requires to know the component, which means it is network bound - or you have to delcare it at spawn, i guess?
<infinity> Daviey: On the buildds, it's declared when you start the job.
<infinity> Daviey: --component=foo --purpose=bar
<Daviey> yeah, but launchpad is lucky enough to know the compoent.
<Daviey> :)
 * Daviey looks up what a compoent is
<infinity> Daviey: That's more than enough to get people to be able to match the archive behaviour for reproducibility.
<infinity> Daviey: I'd argue that if you don't know what component your source package is in, you probably shouldn't be uploading it. :P
<Daviey> infinity: Incidently, i came acorss a package which built fine in pbuilder and sbuild, but failed on the buildd's.  Grabbing the LP chroot, and throwing it into pbuilder allowed me to debug it
<Daviey> infinity: Well, my usecase was automated builds.. so thar! :)
<infinity> Daviey: Yeah, for doing automated rebuilds or something, you could still cheat with the apt Sources.gz and grep-dctrl or some such.
<infinity> Daviey: It wouldn't be up-to-the-minute accurate, but close enough.
<infinity> But you'd want that sort of logic in a wrapper, not in pbuilder/sbuild themselves.
<infinity> pbuilder and sbuild should just trust user input.
<infinity> Not be clever.
<Daviey> Oh aye.. that is what i was doing
<Daviey> infinity: Incidently, i'd like to steal LP's Architecture: $target handling.. Need to see if/how that is exposed via API.
<infinity> Hrm?
<infinity> Not sure I know which Arch handling you're referring to.
<infinity> You mean the part where it selects arch_indep for i386, and passes '-A' to sbuild?
<infinity> If so, that's exposed via the API.  See is_nominated_arch_indep at https://api.launchpad.net/devel/ubuntu/oneiric/i386
<infinity> Daviey: Was that what you were driving at? ---^
 * infinity lunches for real this time.  Honest.
<Daviey> infinity: Well that yes, but also processing of linux-any, and the others
<Daviey> Although, not really an sbuild issue itself.
<Daviey> for each package
<infinity> Daviey: http://paste.ubuntu.com/463055/ <-- The patch that was applied to lp-buildd's sbuild to handle linux-any.
<infinity> Though, I'd assume the distro sbuild does the right thing anyway.
<Daviey> ah, nice
#ubuntu-arm 2011-09-27
<brandini> chatty in here tonight
<tgall_foo> ogra_, slangasek : is it going to be possible to get some sponsorship love for libjpeg-turbo that's in revu?
<lag> Daviey: You're lucky you found _one_ person who would room with you ;)
<twb> SWMBO?
<ogra_> tgall_foo, whats the reason for using that old debhelper version =
<ogra_> ?
<brandini> is the daily from today worth downloading and installing?
<brandini> it'd be great to see what changed between those builds somewhere
<GrueMaster> brandini: You can also just do a "sudo apt-get update;sudo apt-get dist-upgrade" to find out.  On a daily basis, this can be much quicker, especially after Thursday when we go into final freeze.  After that, it is critical bug fixes only.
<infinity> brandini: Unless you're looking for installer changes, there's probably no point in new dailies (or even the final release), just upgrading should be fine.
<infinity> brandini: On the other hand, if you want to help make sure the installation media is in good shape, please do. ;)
<brandini> infinity: both mostly
<brandini> :)
<brandini> but back to my original question... is it good? :P
<infinity> Dunno, haven't used it.
<brandini> :)
<brandini> ok, here I go
<brandini> updated and rebooting
<prpplague> GrueMaster: i really should build more of my panda netbooks
<GrueMaster> Yes, and send one to me.  :P
<prpplague> GrueMaster: with all the new omap4 devices coming out, i would how economical it would be to build some....
<brandini> prpplague: got pictures?
<prpplague> http://www.elinux.org/PandaBoard_Netbook
<brandini> my friend is building one of those, would you be interested in doing one for him?
<prpplague> hehe, i would love to build some more, simple don't have the time
 * prpplague tries to remember a quote from roscoe brown in the cowboys
<brandini> time is money?
<brandini> is it possible to turn off wifi/bt from the command line?
<brandini> I don't use them and I'd like to disable them
<prpplague> yea if you export the gpio controls
<sniperjo_> whats the best way to install dependancies on a chroot environment?
 * brandini looks up the gpio controls
<brandini> prpplague: in bsd we have soft and hard switches to control them
<sniperjo_> I'm desperately trying to get lucy running on an omap device, not beagle!  it comes with angstrom. I've swapped the rootfs between the two and it boots up to "Starting GPE display manager" and hangs, any ideas ?
<GrueMaster> lucy?
<sniperjo_> GrueMaster: oops, think i probably meant lucid!
<GrueMaster> Why do you want Lucid?  It was only a tech preview on omap3.
<GrueMaster> And it is due to drop support next month for armel.
<GrueMaster> (18 month support cycle for ports).
<sniperjo_> GrueMaster: because apparently it will work the best with the old kernel that works with angstrom
<GrueMaster> I take it you had issues with ubuntu core?
<infinity> How old is this kernel you're using?
<sniperjo_> GrueMaster: I'm not going to lieâ¦ I've had issues with everything
<infinity> New userspace should work fine with old kernels, generally.
<sniperjo_> infinity , GrueMaster " its 2.6.32
<GrueMaster> sniperjo_: I have used 2.6.31 on a different system (Dove) and had it boot into an oneiric rootfs, so it does work.
 * martyn has just booted an oneric rootfs
<GrueMaster> sniperjo_: What are you currently booting from?  SD?  eMMC/Flash?
<sniperjo_> GrueMaster: SD
<GrueMaster> Ok, how is the SD partitioned?   And do you have a spare SD 4G (or bigger)?
<sniperjo_> GrueMaster: i have a 4gb
<GrueMaster> That can be wiped?
<sniperjo_> GrueMaster: partitioned as their sdcard config script does, one boot, one rootfs
<sniperjo_> yup
<GrueMaster> Ok, clone your working SD onto your spare SD.
<sniperjo_> GrueMaster: ok done!
<GrueMaster> Make sure the spare boots.
<sniperjo_> GrueMaster: it works
<GrueMaster> Ok, power off, and move the SD to your PC.  BTW, what are you running on your PC?
<sniperjo_> ubuntu netbook, 2.6.32-33
<GrueMaster> Ok.  Old, but ok.
<GrueMaster> On the netbook, insert the SD, but make sure it is unmounted.
<sniperjo_> ok
<GrueMaster> What drive is it (/dev/mmcblk0, /dev/sdb, etc)?
<sniperjo_> sdb
<GrueMaster> Ok, no format the second (rootfs) partition with "sudo mkfs.ext3 /dev/sdb2" (no quotes).
<sniperjo_> GrueMaster: ok, done
<GrueMaster> Ok.  Now, do you have a copy of ubuntu-core?  If not, "wget http://cdimage.ubuntu.com/ubuntu-core/releases/oneiric/beta-2/ubuntu-core-11.10-beta2-core-armel.tar.gz"
<sniperjo_> i have ed2e64d339cb4fc89c8965e6717d6d3e  oneiric-core-armel.tar.gz
<GrueMaster> Looks like it is the same one.
<GrueMaster> In the directory where that tarball is, make a mnt directory "mkdir mnt".
<sniperjo_> ok
<GrueMaster> Now, "sudo mount /dev/sdb2 mnt"
<sniperjo_> ya
<GrueMaster> Next, "cd mnt" followed by "sudo tar -zxvf ../oneiric-core-armel.tar.gz"
<GrueMaster> That should finish rewriting your rootfs with the ubuntu-core.
<sniperjo_> yup
<GrueMaster> ok, "cd .. ; sudo umount mnt"
<GrueMaster> Wait for it to flush any cache writes.
<GrueMaster> Then try that SD in your system.
<sniperjo_> GrueMaster: ok, it has a massive spas out on udevd[2861]: unable to receive ctrl connection: Function not implemented
<sniperjo_> as in it just keeps on repeating it
<GrueMaster> hmm.
<sniperjo_> also a modprobe: FATAL: Could not load /lib/modules/2.6.32/modules.dep: No such file or directory
<GrueMaster> That is to be expected at the moment.  No kernel in ubuntu-core rootfs.
<GrueMaster> It should still give you some sort of prompt.
<GrueMaster> Is this serial console or on screen?
<sniperjo_> http://pastebin.com/ukRiFiaB
<sniperjo_> GrueMaster: Serial console.
<GrueMaster> ok.  need to make a tweek to the rootfs.  Shut it down and move the SD back to your netbook.
<sniperjo_> ok, unmount ?
<GrueMaster> mounted.
<sniperjo_> good to go!
<GrueMaster> ok.  Easiest is to do the work in a terminal.  cd to the mount point.
<GrueMaster> and cd etc
<sniperjo_> yup
<GrueMaster> then type "sudo cp init/tty2.conf init/ttyO2.conf
<sniperjo_> yup
<GrueMaster> then "sudo vi init/ttyO2.conf" and change "exec /sbin/getty -8 38400 tty2" to "exec /sbin/getty -L ttyO2 115200"
<sniperjo_> yup
<GrueMaster> Save, cd away, unmount and reboot.
<GrueMaster> See if that gives to a console shell.
<sniperjo_> no looked like their might of been a longer pause, but then same error
<sniperjo_> udevd[2861]: unable to receive ctrl connection: Function not implemented
<GrueMaster> Does hitting enter on the serial console bring up anything?
<GrueMaster> What is the kernel cmdline?
<GrueMaster> (scroll up to see).
<sniperjo_> enter does nothing and
<sniperjo_> GrueMaster: where am i meant to be looking ?
<sniperjo_> for uboot ?
<GrueMaster> As the system boots, after "Uncompressing Linux... done, booting the kernel."
<sniperjo_> err "Linux version 2.6.32 (root@edward-desktop) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #20 Fri Aug 6 13:54:51 CST 2010" ? its all on http://pastebin.com/ukRiFiaB
<sniperjo_> GrueMaster:  Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
<sniperjo_> sorry, diddnt see it
<GrueMaster> Got it.  Ok, need to reedit.
<sniperjo_> ok I'm back in ect
<sniperjo_> etc even
<GrueMaster> excellent.
<GrueMaster> Ok, "sudo mv init/ttyO2.conf init/ttyS2.conf"
<GrueMaster> Then "sudo vi init/ttyS2.conf" and replace ttyO2 with ttyS2.
<GrueMaster> That "should" now give you either a terminal or a login on the serial console.
<sniperjo_> GrueMaster: still the same
<GrueMaster> pressing enter should give you something.
<sniperjo_> GrueMaster: still the same
<GrueMaster> Are you using the keyboard on the serial-console system or a keyboard attached to the test system?  use the serial-console system.
<sniperjo_> still have "udevd[2861]: unable to receive ctrl connection: Function not implemented" that comes up 15x a sec, and pressing enter just adds a like between wherever it is printing
<sniperjo_> GrueMaster: yes, its all going through a modem
<sniperjo_> & minicom
<GrueMaster> modem?
<sniperjo_> well, usb / serial adapter
<sniperjo_> lol
<GrueMaster> Ok.  BIGGGG difference.  :P
<GrueMaster> Lose minicom.  It is a pita.
<sniperjo_> i had some awful belikin thing before which was one
<GrueMaster> Just type "screen /dev/ttyUSB0 115200"
<GrueMaster> That should give you a better serial console.
<sniperjo_> ok, but its still the same !
 * infinity glares at sys/ucontext.h on ARM.
<GrueMaster> Ok.  Next we will need to disable udevd.  Shut down and prepare to edit while I look at my systems.
<sniperjo_> ok, thanks so much
<GrueMaster> Looks like we can just edit etc/init/udev.conf.  Comment out the "exec udevd --daemon by adding a # to the beginning of the line.
<sniperjo_> ok, and try again ?
<GrueMaster> yep
<sniperjo_> GrueMaster: ok, so by the looks of it now, its just stopped before where the udev would start spamming it , enter does nothing
<GrueMaster> hmmm.
<GrueMaster> Not sure what the issue is now.  I'll muck with some stuff here on a different system and see if I can recreate the environment.  But first, I need food (haven't eaten all day).
<sniperjo_> GrueMaster: ok, that would be amazing
<sniperjo_> thanks for your help again!
<GrueMaster> sniperjo_: One other thing, you might want to keep and eye on https://wiki.ubuntu.com/ARM/PBlueprintIdeas.  One of the blueprints for next cycle is to help enable other consumer devices.  For the most part, yours may be failrly simple (like patching u-boot & kernel to ID your board).
<GrueMaster> If you can make it to Orlando Florida the first week of November, you can discuss it in person, otherwise you can monitor the sessions in IRC and comment where appropriate.
<sniperjo_> i'd love to, but its a bit far !
<GrueMaster> Getting full support for your system in Oneiric is unfortunately not going to happen.  We have final freeze Thursday, with only critical updates after that.
<GrueMaster> But I can try to help a little as time allows.
<GrueMaster> For now, lunch.
<sniperjo_> GrueMaster: yea thats great, I'm only really looking for something that will play nice with chromium and mplayer at the moment!
<rsalveti> http://techcrunch.com/2011/09/26/amazon-kindle-fire/
<rsalveti> wow, everything is omap now :-)
<rsalveti> probably omap 4
<GrueMaster> Would explain why pandas are hard to buy.
#ubuntu-arm 2011-09-28
<brandini> what does the one LED that flashes all the time mean on ubuntu?
<infinity> ?
<infinity> On which hardware?
<brandini> the pandaboard
<brandini> the hardware specs say that it's user defineable
<infinity> "STATUS1" (the LED furthest from the SD card on a Panda) is USB activity, I believe, and STATUS2 is SD activity.
<infinity> I'm not positive on the STATUS1 thing, though.
<infinity> It does seem to go up when I shove things through the USB bus, though. :P
<infinity> I suspect the kernel knows for sure.
<brandini> hrmmm
<rsalveti> brandini: heartbeat
<rsalveti> one is for heartbeat and the other is for sd activity
<infinity> rsalveti: It's a pretty inconsistent heartbeat.
<rsalveti> infinity: well, depends on the cpu usage
<brandini> mine seems regular enough :)
<dash> woo hoo, got my mx53
<dash> looks like it's got its own kernel package. anybody using natty with this board?
<ria_> hi, i have installed ubuntu 10.10 on my pandaboard, kernel version  2.6.35-903-omap4 #14-Ubuntu SMP PREEMPT
<ria_> i am getting the following error during startup
<ria_>  Unhandled fault: imprecise external abort
<ria_>  Internal error: : 1406 [#2] PREEMPT SMP
<ria_> ...
<ria_> Process pulseaudio (pid: 1273, stack limit = 0xae4e42f8)
<ria_> any idea what is wrong with my system?
<twb> Use a pastebin if you have lots more lines
<twb> Dunno about the error, but disabling pulseaudio would seem to be a good first thing to try
<ria_> couldnt get the totem player to work... it reports "cannot connect to server.... jack server is not running or cannot be started"
<twb> I dunno about GUI stuff
<twb> If you just want to test sound try aplay(1)
<twb> jack and pulseaudio are huge behemothic things, it wouldn't really surprise me if they fell down and died for some silly reason on non-x86 hardware
<ria_> thanks i'll give it a try
<sniperjo_> Hi guys, I've got 2.6.32 running with an oneiric roots. when booting it seems to get to" udevd[2861]: unable to receive ctrl connection: Function not implemented" and then just repeats this over and over again. Any ideas ?
<Jack87> (
<twb> sniperjo_: it wouldn't surprise me if oneiric simply doesn't work with a kernel that old
<twb> It sounds like udev vs. kernel version incompatibility to me
<sniperjo_> GrueMaster and infinity  seem to think there wouldn't be too much of a problem with the kernel
<sniperjo_> twb:  basically i have a working version of angstrom and I'm looking to get ubuntu on it. this is the angstrom kernel is quite old !
<twb> I would try to make lucid work first, since that shipped with .32
<sniperjo_> twb: I've been trying for the past week solid to do it! what would you recommend, just swapping the roofs over ?
<twb> I'm no expert, man
<twb> I can't even get a new bootloader to work on my device
<sniperjo_> I'm not the only one who has problems then!
<infinity> sniperjo_: Hey, don't drag me into this.  I didn't say 2.6.32 would work. :)
<infinity> But yeah, looks like a kernel/userspace disagreement with udev. :/
<twb> I expect there is an anti-udev bigot in the audience who would like to interject at this point :P
<infinity> I used to run udevless all the time.  But I'm not sure if MAKEDEV will actually create all the nodes his system needs to get away with it.
<twb> But udev does all sorts of extra, scary shit now
<sniperjo_> infinity: i thought you said something along the lines of new userspace should work fine with older kernels, or something like that ! :P
<twb> sniperjo_: well, in theory it should
<infinity> sniperjo_: Well, in every respect other than udev, sure.  Old kernels and new chroots are happy.
<sniperjo_> well last night we ended up disabling udev, and still don't seem to get a login prompt
<infinity> No udev means no devices.
<twb> Isn't there some kernel pseudofs that can do it instead of MAKEDEV
<infinity> If you can chroot into that system and "cd /dev && MAKEDEV" it might fix you up.
<twb> sniperjo_: also if you refer to e.g. root=LABEL=fred you need udev
<infinity> twb: devfs might be dead.  If it's not, it should be.
<twb> infinity: I had some memory that it was used before udev in the initramfs-tools or something
<twb> I'm probably just misremembering
<sniperjo_> something like Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait ?
<twb> sniperjo_: does mmcblk0p2 exist when you just mount the rootfs somewhere?
<twb> The device file, I mean, inside /mnt or wherever you mount it
<infinity> Almost certainly not.
<sniperjo_> twb: arm no, i think its a function of board
<twb> Ya so fix that
<sniperjo_> twb: how?
<twb> 17:39 <infinity> If you can chroot into that system and "cd /dev && MAKEDEV" it might fix you up.
<sniperjo_> ah i missed that
<sniperjo_> so boot in with angstrom and try it?
<infinity> And then disable udev again, so it stops having a hissy fit.
<infinity> Well, after you MAKEDEV, check and see if the device node you need is there.
<infinity> If it's not, you'll get to look up the major and minor of mmcblk* and mknod. :P
<infinity> (I can't imagine why we replaced all this with automation)
<twb> sniperjo_: no just chroot in from a real machine
<sniperjo_> twb: ok, because i was just about to say, chroot from the arm could be a little challenge
<twb> infinity: obviously what we should be doing is just referring directly to /sys/dev/<major>/<minor> and forego this wussy "naming" thing
<sniperjo_> erm for some reason Ichroot  media/de74c7e5-118c-4da7-b7a9-858cf661c650 ,: chroot: cannot run command `/bin/bash': No such file or directory
<infinity> sniperjo_: Err, you can't chroot from a non-ARM system into an ARM one.
<sniperjo_> infinity: twb: sniperjo_: no just chroot in from a real machine
<sniperjo_> ah ok
<infinity> A real ARM machine? ;)
<sniperjo_> ah, that bit was lost in translation !
<infinity> (You could do it with qemu-user-static, I suppose... But I'm too tired to walk through setting that up for chroots)
<infinity> Well, it's not rocket science, I guess.
<infinity> You install it in the host, "dpkg -L qemu-user-static", grab the *arm* binaries and place them in the same filesystem location in the chroot.
<infinity> I think it's way past bedtime here, though.
<sniperjo_> same file system location ?
<sniperjo_> lol
<sniperjo_> are you sure you don't want to solve an un-solvable problem ?
<ogra_> bah, the answer tracker of LP sucks
 * ogra_ just asked a question janimo asked already :(
<janimo> ogra_, which question?
<ogra_> "cant install from usb stick"
<ogra_> i use to read my mails in order but somehow the mails from the answer tracker dont get threaded anymore
<ogra_> i guess that happens if someone answers by mail directly instead of using the web ui or so
<janimo> so you asked or answered the same question?
<ogra_> well, i asked if he had partitions at all
<janimo> ah ok
<ogra_> just to see a few mins later that he has a fourth partition but no others
<janimo> yet another mobile operating system with intel cofounding  - tizen.org
<janimo> dithcing native linux app stack for html
<ogra_> doesnt mozilla do that as well ?
<ogra_> funny that everyone tries to reimplement webos :)
<janimo> I think ti actually is a better dev platform than the mixed crack we have now in ubuntu
<janimo> html5 & co that is
<ogra_> sure, i would have gone for a webos solution years ago :)
<ogra_> but implementing the desktop apps in html/javascript wasnt the answer it seems :)
<ogra_> janimo, btw, you run bootchart on your ac100 ?
<ogra_> how do you fit that into the initrd ?
<ogra_> my system blows up if i pass the 3.something Mb
<ogra_> (for the compressed initrd)
<janimo> ogra_, I did not even know boothcart is put in intrd - althought it makes sense
<janimo> My boot part is 8 Mb
<ogra_> mine too
<janimo> I built a kernel with all ac100 modules (~35) as builtins
<ogra_> the bootloader falls over of you get somewhere between 3-4M
<janimo> and it grew by less than 1.5M
<janimo> ogra_, not here apparently
<ogra_> yeah, the kernel size isnt the prob
<ogra_> how big is your initrd atm ?
<janimo> les than 2M
<ogra_> aha
<janimo> I doubt bootchart would be that big
<ogra_> it has deps
<janimo> standard ac100 from package
<ogra_> i wonder how you got it that small
<ogra_> thats a default install ?
<janimo> yes
<ogra_> weird
<ogra_> mine is 2.9M
<janimo> ok, letme double check then
<ogra_> close to the edge of falling over
<ogra_> though this is my upgraded natty
<ogra_> if we actually end up with less than 2 i can turn plymouth back on !
<janimo> ogra_, ramdisk 2.19 Mb
<ogra_> hmm
<janimo> time to test our daily images don;t you think :) ?
<sniperjo__> join /#angstrom
<sniperjo__> wooops
<ogra_> well, i still have a few bugs to fix on omap4
<ogra_> and in the ac100 installer
<janimo> and doing the work on the ac100 for it?
<ogra_> sure
<janimo> don;t you have one just for testing?
<janimo> anyway I can run bootchart fine
<ogra_> well, currently its a builder
<ogra_> great
<janimo> but found no low hanging fruit :(
<janimo> boot varies betwen 38 and 45 secs
<janimo> even without changes, not alwaay determinitsic
<ogra_> did you upload the png somewhere ?
<janimo> not yet, but I plan to
<ogra_> k, point me to it once you have :)
<janimo> I thought it is so easy to run and without an analysis I did not start uploading yet
<ogra_> i'd like to see the IO
<janimo> I tried disabling readahed but little effect
<ogra_> well, it requires a reboot :)
<janimo> I tried building all modules in the kernel, again no visible effect
<janimo> well I am at bootvchart png-20 so I guess  I have afew reboots :)
<janimo> for some reason I was expecting significant gains from modules being builtin
<ogra_> heh, no
<janimo> but apparently modprobe is very fast nowadays
<ogra_> and we only load them late
<ogra_> initrd doesnt contain any modules by default
<janimo> they are loaded during boot in the first 40 secs
<janimo> no modules in initrd?
<ogra_> right, but after you moved to the actual root
<ogra_> no, that would make it over 4M
<ogra_> the installer puts an initrd config in place with MODULES=dep set ...
<ogra_> (which is equal to no modules)
<ogra_> well, i'm lying ... if you actually install a package that forcefully drops a module into the initrd you will indeed have modules :)
<ogra_> i.e. mdadm or lvm userspace stuff
<ogra_> or cryptsetup
<brandini> I'm having trouble getting the TI addons installed
<ogra_> what release ?
<brandini> Unable to locate package ubuntu-omap4-extras
<ogra_> they only fully exist for maverick (10.10), for natty (11.04) TI didnt provide any
<brandini> I'm on the daily from 09/26
<brandini> ahhh ok
<brandini> :)
<ogra_> ah, yeah, not done yet
<ogra_> it should be ready by release
<brandini> I wonder if that's what's causing my go time test from failing
<brandini> s/from/to/
<xranby> brandini: if i understand the situation correctly, ti do not make the driver themself   they get it from Imagination Technologies' that own the design for the POWERVRâ¢ SGX unit inside the omap
<ogra_> xranby, ubuntu-omap4-extras is a lot more than just the GLES driver
<ogra_> in fact we should have the driver for all releases in the PPA
<ogra_> but the other bits only exist for maverick
<ogra_> iirc ubuntu-omap4-extras-graphics should be installable on all but oneiric atm
<ogra_> (not sured if rsalveti added a metapackage for -graphics when uploading the driver to the PPA)
<sniperjo__> Hi guys, I've got 2.6.32 running with an oneiric roots. when booting it seems to get to" udevd[2861]: unable to receive ctrl connection: Function not implemented" and then just repeats this over and over again. Any ideas ?
<ogra_> get a newer kernel, thats a typical error for the kernel missing bits for udev support
<sniperjo__> ogra_: My board only seems to work with this kernal
<sniperjo__> GrueMaster: seemed to think i would be able to do a little changing to get it to work
<xranby> sniperjo__: the target kernel for oneiric are 3.0    the ac100 are an exception that will still use 2.6.38
<xranby> sniperjo__: which board are you using?
<sniperjo__> a technexion tsunamipack, omap3530
<ogra_> sniperjo__, there is surely a way to do it without udev, how much of userspace breaks throught it missing is hard to predict though, xorg and friends for example rely on udev info
<sniperjo__> the board comes with angstrom with that kernel, and id like to get at least lucid on it
<sniperjo__> the guys here last night thought going for the newest rootfs
<ogra_> well, ask the vendor for the source i'd say
<ogra_> and switch on SIGNALFD or whatever udev misses in your build
<ogra_> after all its linux, and its unlawful for them to not give you the source if ou bought their board
<sniperjo__> del we ended up disabling udev last night, but still diddnt get a console
<sniperjo__> i have all the source
<ogra_> because you dont have devices i guess
<ogra_> well, then rebuild your kernel !
<sniperjo__> i have no idea how to, I've spent the last week  following every possible tutorial
<ogra_> you take your source, unpack it, geta cross compiler, run make menuconfig in the source tree and make zImage
<sniperjo__> I've been on here everyday a sing about swapping rootfs and other ways around it
<ogra_> why work around it if you can make it work properly
<ogra_> really, kompile your own kernel with the right options and be done
<ogra_> *compile
<sniperjo__> how long would that take ?
<ogra_> 1h or less
<ogra_> cross builds should be pretty fast
<sniperjo__> i need to find someone to help me ....
<ogra_> http://marcin.juszkiewicz.com.pl/2010/10/19/how-to-cross-compile-arm-kernel-under-ubuntu-10-10/
<sniperjo__> followed that
<ogra_> well, then you should have a uImage
<ogra_> (you dont need xdeb btw, since you dont build any packages)
<ogra_> (you only want the last paragraph actually)
<janimo> sniperjo__, indeed, that is what I use and it works fine
<sniperjo__> ogra_: do i need to add any repos ? linux-source-2.6.35 can't be found
<ogra_> sniperjo__, why would you want that ?
<janimo> sniperjo__, which kernel do you want to build? what device?
<ogra_> you said you have the source of your vendor
<janimo> you need to get the appropriate source for that
<ogra_> so you indeed want to build that one
<ogra_> apt-get install gcc-arm-linux-gnueabi
<sniperjo__> ok so, what would the source look like ?
<ogra_> thats all you should need
<ogra_> you said you have it ?
<ogra_> you should know how it waqs given to you
<sniperjo__> well i have all the files nessasary to make an sd card
<sniperjo__> they use the code sorcery arm
<ogra_> sure, that doesnt matter
<ogra_> well, if you have a kernel tree (likely a tarball) you need to unpack it
<sniperjo__> i just downloaded the newest g++ lite from their site
<ogra_> you are not on ubuntu ?
<sniperjo__> i am
<ogra_> well, then use the ubuntu gcc
<ogra_> dont fiddle with an unpacked compiler
<sniperjo__> ok, so could you tell me how ?
<ogra_> apt-get install gcc-arm-linux-gnueabi ... as i said above
<sniperjo__> yup, installed
<ogra_> k
<ogra_> now go to the kernel source tree
<ogra_> run make menuconfig in there (you might need to install libncurse5-dev if it complains)
<ogra_> then run: ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage modules
<ogra_> and it will build a uImage and the matching modules
<sniperjo__> what options do i want to select in the kernel config ?
<ogra_> dunno, you need to ask a udev developer i guess
<ogra_> signalfd is definitely needed
<ogra_> and inotify support
<sniperjo__> ogra_: armâ¦ its asking me a lot of questions I'm just pressing enter for
<ogra_> oh, wiat
<ogra_> *wait
<ogra_> can you boot the existing system on your device and get the running config from there (cat /proc/config.gz)
<sniperjo__> (I've gone through about a 50 questions)
<ogra_> using the output of that should get you a good starting config
<ogra_> yeah, stop it
<ogra_> you dont want that
<sniperjo__> oh ok
<ogra_> you need a default config to base on, else you will need to answer each and every question (and you need to answer them right)
<ogra_> cat /proc/config.gz > my_new.config.txt
<ogra_> that will copy the running config on your angstrom into the file my_new_config.txt
<sniperjo__> yup ok
<ogra_> that file you can copy to your source tree as .config
<ogra_> (note the dot)
<ogra_> then run make menuconfig again and it shouldnt ask anymore
<sniperjo__> if run menuconfig it still lasks
<ogra_> you copied the config into the right place ?
<xranby> sniperjo__: are you using the source tree that came with your board?
<ogra_> it usually doesnt, at least if the source is identical to the binary you run
<sniperjo__> yup, they have same mf5
<sniperjo__> md5*
<ogra_> right, i was assuming you use the kernel tree of your vendor that also just runs as binary on your angstrom
<sniperjo__> there is a file, called kernel in the files i downloaded from the manufacturers website, has the .config and the files you are talking about
<ogra_> and a full kernel tree too ?
<ogra_> janimo, how is mx5 looking ? final freeze is tomorrow so we should have them in shape today
<janimo> yes, about to test the latest image
<ogra_> great
<ogra_> we only have tomorrow for emergencies
<sniperjo___> is that the right kinda sounding place / file ?
<xranby> sniperjo__: yes sounds like the right file..
<xranby> sniperjo__: you can cross check that the Makefile contains the same kernel version as  your bopard report when running  uname -a
<sniperjo___> if i do ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage modules, i get a bunch of warning for config : unexpected data, then i get a prompt for development of incomplete code / drivers
<sniperjo___> angstrom is 2.6.32 i think, how do i check the make file
<xranby> sniperjo___: try gedit Makefile
<xranby> the version number are displayed at the top
<janimo> sniperjo___, what is your boards config file? arch/arm/configs/xxx_defconfig
<janimo> you need to add that in the make on first run
<janimo> so ..... make XXX_defconfig
<janimo> then uImage
<ogra_> that shouldnt be needed if .config is there and he uses the right tree
<sniperjo___> the make file came with the files that make the SD so its  the same
<sniperjo___> 2.6.32
<ogra_> and that mateches *exactly* the output of uname -r on your angstrom ?
<sniperjo___> arm the manual has stuff in about make omap3_tsuanami_defconfig
<sniperjo___> the manual is http://www.technexion.com/index.php/support-center/downloads/ti-cpu-modules/tao-3530/549-tao-3530-userguide-0953/download
<ogra_> does your kernel tree have that in the config dir ?
<ogra_> find . -name omap3_tsuanami_defconfig
<ogra_> run that in your tree
<ogra_> if its there, use it as janimo described above
<sniperjo___> it does
<ogra_> well, then try: make omap3_tsuanami_defconfig
<ogra_> and see if it still asks
<sniperjo___> OK config written
<ogra_> well, now find out what the missing options are that cause your error i guess googlong will give you some hints
<ogra_> *googling
<ogra_> then find them in menuconfig and set them to the right values
<sniperjo___> what error ? this is like looking for a needle in a haystack when i don't even know which planet its located on
<ogra_> the error you posted with your first line in here today :)
<sniperjo___> ogra_:  that was with the oneiric core
<ogra_> which you want to get running or not ?
<sniperjo___> yes
<sniperjo___> i just want anything ubuntu > lucid !
<ogra_> so, google for the error messaged in connection with kernel and udev
<ogra_> *message
<ogra_> and see if you can find what config options it needs
<ogra_> then set these and build the kernel
 * ogra_ needs to go mow the lawn ... back later
<xranby> ogra_: have a good oneiric freeze day
<sniperjo___> well.. my error comes up as the first result on patebin....
<sniperjo___> noooooooo
<ogra_> xranby, oh, i'm not finishig my day yet :) just needs to do someting that doesnt involve sitting my butt flat
<sniperjo___> i will pay someone to spoon feed me the information on how to compile lucid or better on my board!
<sniperjo___> i think I'm on the verge of slitting my writs
<sniperjo___> nice to see know ones motivated by money, so who wants to help me without !!!
<xranby> sniperjo___: we are trying our best to help you with all practcall questions..  i think you are the only one here with a tsunami board so you are the only one who can test when it work
<xranby> sniperjo___: if you have a lot of error messages in front of you try paste them all into http://paste.ubuntu.com
<xranby> it will makes us able to give you better hints what to do
<xranby> sniperjo___: and if you get it working, try post what you did into a blog to let other users with a tsunami board know about it
<xranby> sniperjo___: my best reccomendation are that *you* should try describe to someone else how to solve this...  by doing so you will sort your mind and get a better understanding how all the different parts relates
<xranby> sniperjo___: âIf you want to learn something, read about it.   If you want to understand something, write about it.  If you want to  master something, teach it.â ~     Yogi Bhajan
<sniperjo___> xranby:  i have been doing both for the last week, week and a half
<xranby> sniperjo___: excellent
<sniperjo___> xranby: but i haven't succesded
<xranby> you are making progress
<gildean> sniperjo___: i don't see how this doesn't answer your questions mostly: http://www.linsys.fr/index.php/en/whitepapers/linux-lab/start-tsunami
<gildean> just use the toolchain ogra_ adviced
<sniperjo___> gildean: thanks ill have a look at that.
<gildean> sniperjo___: it took you over a week to get to that information which i googled in a few seconds?
<gildean> first you should learn how to google better :D
<sniperjo___> gildean:  good facetious comment, but i have to different boards from the same manufacture, just so happens that i was concentrating on getting the other one up and running, but i gave up
<gildean> just joking, don't take it too seriously
<sniperjo___> its pretty hard not to when you've been trying something so hard for so long
<sniperjo___> but if whatever you posted worksâ¦. i will forgive eyou â¦ :P
<gildean> :D
<GrueMaster> Sometimes, finding the right query for google can be harder than figuring out how to fix something on your own.
<ogra_> ++
<GrueMaster> I know, I have spent days trying to find IPv6 test suites for Linux.
<ogra_> GrueMaster, is there anything you have on your mind we urgently need to get done before final freeze ? we ahve a bit more thna 24h
<GrueMaster> (and please, don't send me more links to whitepapers).
<ogra_> geez, my typing sucks
 * ogra_ only has TI icon, slideshow in oem-config and the partman bit on his mind 
<GrueMaster> ogra_: Nothing stands out so far.
<GrueMaster> When is the Ti icon going to be added?
<ogra_> GrueMaster, its there (always was) but the favorites handling changed
<GrueMaster> Ah.
<ogra_> GrueMaster, i'll work on that tonight/tomorrow
<ogra_> seems its all d-conf now that gconf is done and indeed everything works different
<ogra_> s/done/gone/
<ppisati> guys, did anyone try the new omap4 kernel?
<ppisati> rsalveti: ^^
<GrueMaster> which one?
<ppisati> i would like to pull today
<GrueMaster> I've been doing SRU catchup.
<ppisati> GrueMaster: http://people.canonical.com/~ppisati/linux-image-3.0.0-1205-omap4_3.0.0-1205.10_armel.deb
<ppisati> it has 4460 support
<GrueMaster> I have no board, but can make sure you didn't break existing stuff.  :P
<ogra_> yeah, regression testing on that one is most important
<ndec> ppisati: what did you use for this kernel? which branch?
<ogra_> if 4460 doesnt work there wont be kittens dieing
<prpplague> ogra_: just no beer and chips
<ogra_> 8would be annoying to not have 4460 support, but would be worse to break existing pandas)
<ppisati> ndec: TI BSP update: kernel-tilt/tilt-3.0-nodspvideo1 @ d2fe6284bb37abd542524b17f17cf9208db767c2
<prpplague> ogra_: i am more concerned with the ES2.3 omap4430 based A4 board
<prpplague> ogra_: did the EDID patch for the pullups get merged?
<ogra_> prpplague, we tested that long ago i think
<GrueMaster> A4????
<ndec> sebjan: ^^^
<GrueMaster> I "just" got an A3 last week.
<ogra_> GrueMaster, iirc allison tested that
<GrueMaster> I got her board.
<ogra_> davidm reported it
<ogra_> oh, i thought that was an A4
<GrueMaster> A3
<ogra_> prpplague, well, if we get no HW we cant test much :)
<ogra_> send us HW :)
<prpplague> ogra_: ok, i'll check with nipuna on this
<prpplague> ogra_: i just assumed you had pulled the info
<ogra_> i think ndec is after getting us 4460, not sure if A4 is on his list
<ogra_> we didnt discuss A4 in the weekly calls
<davidm> we were supposed to be getting 2 4460's but none have showed up yet
<sebjan> ppisati: I was about to send you an email about that topic: kernel upgrade
<ogra_> davidm, and A4 ?
<ogra_> (its actually the first time i hear about A4)
<davidm> Have not found any A4's but would want some to test with
<GrueMaster> prpplague: Is there any significant changes in A4 that require software changes?  At this point it is probably too late to fix.
<davidm> I've never heard of an A4 to date
 * ppisati still has an A1
<ndec> sebjan: ppisati is not using the branch with the linaro-3.0 stuff...
<janimo> A$ the rpocessor in the iphone/ipad?
<janimo> A4
<sebjan> ppisati: we have tested this Andy's branch: tilt-linux-linaro-3.0 (de3104d9972327578baf63d6778b3cbd064aef22)
<janimo> oh,m probably panda revision, nevermind
<ogra_> janimo, yeah, they switched to TI now, not trusting their own CPUs anymore
<ppisati> sebjan: but that's the linaro kernel
<ogra_> :P
<prpplague> GrueMaster: two major items, the silicon id needs to be added and the hmdi EDID signals have pullups that need to be disabled
<ppisati> sebjan: we use vanilla + tilt
<ndec> if that were true ;-)
<ogra_> hehe
<sebjan> ppisati: no, it's Linaro base kernel + TI patches
<janimo> ogra_, http://en.wikipedia.org/wiki/Apple_A4 :)
<ogra_> janimo, i know :)
<janimo> ok
<ogra_> i was just sarcastic ...
<janimo> cortex a8+pvr too
<ppisati> sebjan: yep, that's what i meant: linaro + tilt
<ogra_> (a bit)
<ppisati> sebjan: but for ubuntu we use vanilla + tilt
<sebjan> ppisati: I though this is what you wanted for ubuntu in fact
<ppisati> never used linaro-based kernel
<janimo> possibly a lot of new 4460s go the the kindle fire production, ENOTENOUGH for developers
<prpplague> ndec: just sent you an email regarding the ES2.3 omap4430
<prpplague> ndec: any idea if the required items have been merged into the ubuntu release?
<sebjan> ppisati: ok, I am confused, this is not what I remember we were supposed to use
<prpplague> GrueMaster / ogra_  got a url i can browse the kernel release?
<janimo> the mx5 bootup/installer is very slooooow
<ogra_> ppisati, ^^ can you point prpplague to the current ti tree we use ?
<GrueMaster> ppisati: Can you supply prpplague with a kernel url?
<ppisati> sebjan: all the oneiric/omap4 kernels are based off vanilla + tilt stuff (agreen kept a branch just for this) + ubuntu sauce
<ppisati> sebjan: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-oneiric.git;a=summary - check the ti-omap4 branch
<sebjan> ppisati: right I know, but I though it was while waiting for the linaro integrated version (with all other features)
<ppisati> prpplague: here is the new kernel
<ppisati> prpplague: http://people.canonical.com/~ppisati/linux-image-3.0.0-1205-omap4_3.0.0-1205.10_armel.deb
<ppisati> prpplague: and here is the src code http://kernel.ubuntu.com/git?p=ppisati/ubuntu-oneiric.git;a=summary ti-omap4-next
<ppisati> sebjan: for oneiric? not really AFAIK
<ppisati> sebjan: btw tomorrow is final freeze (kernel freeze was some weeks ago)
<ppisati> sebjan: so...
<ppisati> sebjan: perhaps someone from linaro wanted to manatin a linaro/ubuntu omap4 kernel
<ppisati> *mantain
 * ogra_ doubts that
<ogra_> usually linaro isnt intrested in our kernels beyond comparing to theirs
<ppisati> ok
<ppisati> but were you aware of any switch to linaro kernel for O/omap4?
<ogra_> no
<ppisati> ok
<ppisati> so we are in sync :)
<ogra_> wont happen
<ogra_> unless they change their support model
<ogra_> (and security model)
<ogra_> which i think wont happen within the next few releases
<sebjan> ppisati: ok, so I'll have to test your kernel now
<sebjan> ppisati: + I need to check your pvr module name, and you may need 2 additional patches for that
<ogra_> i think rsalveti prepared all that stuff already (but better check twice)
<ppisati> sebjan: no prob, send it to me
<rsalveti> all needed patches are at the tilt tree already
<rsalveti> ppisati: sorry, will test your kernel deb in a few
 * ogra_ thought so
<rsalveti> we have a critical bug at the linaro side noew
<ogra_> yeah, display issues
<sebjan> rsalveti: yes, but which tilt tree :) that's the question
<ppisati> no prob, i'll still be around for... 6 hours? more or less
<GrueMaster> prpplague: According to http://omappedia.org/wiki/PandaBoard_Revisions#Rev_A4_.28LATEST.29 A4 is identical to A3 except ES2.3 Silicon.  If there are board changes as well, how will they be identified, if the board ID hasn't changed?
<rsalveti> sebjan: the tilt-linux-3.0
<prpplague> GrueMaster: there are no board changes, it is all ES2.3 related
<prpplague> looks like rsalveti has gotten the correct support added
<GrueMaster> I thought you said there were HDMI EDID changes?
<prpplague> GrueMaster: inside the silicon
<prpplague> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-oneiric.git;a=commit;h=58b36b7ce571c5b5cd6b8bc6b29f45eccc7a5f34
<sebjan> rsalveti: this branch does not exist. Do you mean tilt-linux-linaro-3.0, or tilt-3.0-nodspvideo1?
<rsalveti> sebjan: sorry, tilt-linux-linaro-3.0
<sebjan> rsalveti: right, this is the branch I tested so far, but this is not the branch that is beeing integrated into the Ubuntu kernel
<sebjan> the tilt-3.0-nodspvideo1 is being used (which does not include the linaro tree merge)
<prpplague> GrueMaster / ogra_ looks like the support for es2.3 a4 pandaboards should be good
<prpplague> i'll clone a copy and test
<GrueMaster> ppisati: Testing your linux-image-3.0.0-1205-omap4_3.0.0-1205.10_armel.deb kernel now.  This has the A4 & 4460 fixes, right?
<prpplague> GrueMaster: yes according to ppisati
<ppisati> GrueMaster: yep
<prpplague> GrueMaster:  this is the primary one of concern http://kernel.ubuntu.com/git?p=ppisati/ubuntu-oneiric.git;a=commit;h=58b36b7ce571c5b5cd6b8bc6b29f45eccc7a5f34
<GrueMaster> ppisati: On bug 855969, the audio part is because the alsa driver (kernel) renamed the analog hardware device from SDP4430 to Panda.  Do we want to change the kernel or the alsaucm files?  Kernel would (in my opinion) be easier.
<ubot2> Launchpad bug 855969 in linux-ti-omap4 "excessive messaging in dmesg by kernel on omap4" [Undecided,Fix committed] https://launchpad.net/bugs/855969
<rsalveti> GrueMaster: at the ubuntu-leb we changed the alsaucm files already, but at this point just not updating the kernel code is probably easier
<GrueMaster> So, how come no one updated the bug with this info?
<rsalveti> because this was done monday/yesterday
<rsalveti> and we still didn't get everything working for the release
<rsalveti> I added a comment at the no sound support for omap4 bug
<rsalveti> saying that this changed
<ndec> ppisati: ogra_: i think we have always said we would use the tilt kernel for ubuntu. what you are using right now is 3.0 + omap patches but it's missing the linaro-3.0 branch. that's what sebjan meant earlier.
<ndec> linaro and us are using the tilt-linux-linaro-3.0 branch
<rsalveti> that was what I thought too
<ogra_> didnt paolo say we use tilt above ?
<ndec> that's what we discussed many times in our weekly ;-)
<ndec> ogra_: there are 2 main branches. titl and titl-linaro
<ogra_> ah
<ppisati> yep, we use tilt
<ppisati> TI landing tree
<ppisati> not the tilt + linaro kernel
<ndec> it's probably too late now... but you should have used tilt-linaro...
<ppisati> GrueMaster: is it something we can fix after the upload? i would like to pull req before end of day
<GrueMaster> After the upload?  You mean after release?
<ogra_> ndec, especially since tilt+linaro doesnt work atm
<ndec> ppisati: you will need couple of patches from sebjan to revert the DRM driver name in the kernel. or the GFX packages won't work.
<rsalveti> tilt+linaro does work
<ppisati> ndec: since O/omap4 kernel hit our archive we always used vanilla + tilt + ubuntu sauce
<ndec> what does not work?
<rsalveti> is the one we use at the lebs
<ogra_> rsalveti, you got the DVI issue fixed ?
<ppisati> we had many discussions about it in the past
<rsalveti> ogra_: which issue?
<ogra_> rsalveti> we have a critical bug at the linaro side noew
<ppisati> i even have an email i sent to agreen back in... june? july?
<ppisati> where i told him we were using vanilla + tilt
<ndec> ppisati: yes. it's just your definition of tilt that was not correct
<rsalveti> ogra_: oh, that's the sound issue, not related with dvi
<ppisati> ah ok then...
<ogra_> ah, i only saw that displays dont work anymore
<ndec> rsalveti: what issue with sound?
<ogra_> during the day in #linaro
<ogra_> ndec, device was renamed
<rsalveti> ndec: packaging issue, we can't generate hwpacks anymore
<rsalveti> but I'm fixing that
<ogra_> oh, something totally different
<rsalveti> yup
 * ogra_ better shuts up 
<ndec> which device? where?
<ogra_> ndec, the asla device
<ndec> rsalveti: btw awesome work on cross building kernel + dkms ;-)
<ndec> jcrigby: thanks for that ^^^
<rsalveti> ndec: kuddos to jcrigby
<ndec> ditto!
<ndec> do you think it's upstreamable?
<ogra_> "SDP4430" vs "Panda" for the alsa device
<rsalveti> he even fixed another annoying issue for systemtap
<ndec> even better...
<rsalveti> now you just need to install the kernel debug package and it just works :-)
<ndec> we tried dkms earlier, not systemtap yet
<rsalveti> ndec: it should be, maybe we can put it at ppisati last respin
<ppisati> actually the kernel freeze was some time ago, but it _seems_ we can still have an upload like this before tomorrow
<ppisati> but fix can still go in before releae
<ppisati> so if you can't make it today, we can do it later
<GrueMaster> ogra_: bug 779410
<ubot2> Launchpad bug 779410 in flash-kernel "package initramfs-tools 0.98.8ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Confirmed] https://launchpad.net/bugs/779410
<ogra_> that really doesnt state it happens every time (and to be honest i have nevber seen it)
<GrueMaster> It isn't an everytime occurance, but it is very high on some of my SD cards.  Higher on some than on others.
<ogra_> well, if a sync fixes it we should have the in the pipe as a last resort fix, but should still investigate aa real fix
<ogra_> i cant reproduce it here ... but would suggest an upload with an lsof in the code before the umount so we get logs about whats open
<ogra_> and then find out why thats the cas
<ogra_> e
<infinity> I see no reason to upload for that.
<ogra_> well, if its reliably reproducable there doesnt need to be an upload indeed
<infinity> If Tobin has cards he can reliably reproduce this on, give him a hacked-up f-k to play with.
<ogra_> right
<GrueMaster> sigh.  3rd time through ubiquity on this particualr SD card.
<GrueMaster> Checking logs now.
<infinity> And if no one can reliably reproduce it, a debug upload 1 day before final freeze won't help anyone.
<ogra_> well, if its serious enough we can have twn other uploads
<ogra_> *ten
<infinity> Yes, but not debug code.  Please.
<GrueMaster> Sorry, I have been too busy this cycle to test daily desktop images.
<infinity> The archive is not a test bed.
<ogra_> yeah
<ogra_> GrueMaster, nobody is blaming you for anything
<ogra_> i know that bug since it exists, i even discussed it with skaet before
<GrueMaster> Yea, but if I don't do it, it doesn't happen.
<ogra_> and was under the impression its not reliably reproducable nor that it happens often actually
<ogra_> reather blame me for not taking it serious enough before excusing missing tests
<ogra_> *excusing for
<GrueMaster> Yea for useless log output.  I see absolutely no usefull information from ubiquity as to why it keeps restarting.
<GrueMaster> Like this from oem-config.log:  (oem-config:13199): Gdk-WARNING **: oem-config: Fatal IO error 0 (Success) on X server :0.
 * GrueMaster never knew success was a fatal error.
<ogra_> i think thats actually after X died
<ogra_> the real error would be before somewhere
<ogra_> if it would be in that log
<GrueMaster> The rest of the log shows a ton of dbus errors.
<GrueMaster> But that hasn't changed in a long time.
<ogra_> yeah, its more likely you will find info in syslog i think
<GrueMaster> I'm scrolling through it now.
<GrueMaster> AHA!
 * ogra_ is all ears
<GrueMaster> http://paste.ubuntu.com/698627/
<ogra_> GrueMaster, well, add an lsof to flash-kernel before the umount $TEMPFS
<ogra_> err
<ogra_> TMPMOUNT
<ogra_> probably redirect to some file so it doesnt spill into syslog
<infinity> lsof takes just long enough to start that it fixes the race. :P
<infinity> Which is why I suspect sync appears to fix it too.
<GrueMaster> That would be my guess.
<infinity> (I can reproduce it in a loop here without lsof, but with it, no issues)
<infinity> Whatever.  Path of least resistance for now is just to sync(1) before both umounts.  I'll try that in a loop of a few thousand and see if it helps.
<ogra_> lets add a sleep 1
<ogra_> :)
<infinity> Time to kill an SD card.
<infinity> set -e; for i in `seq 1 1000`; do flash-kernel; done
<infinity> ^-- We'll call that good enough?
<ogra_> argh
<ogra_> thats evil
<infinity> I weep for my poor SD card.
<ogra_> yeah
<ogra_> expense it
<GrueMaster> Pfft.  They're cheap.
<infinity> This one wasn't.  But I'm too lazy to swap to a cheap one, so my own fault.
<infinity> We could lazy umount here too.
<ogra_> we rm -rf the dir
<infinity> That's fine.
<ogra_> not sure how clever that is, does lazy actually unmount or does it only mangle mtab ?
<infinity> Lazy detaches it from that directory.
<ogra_> k
<ogra_> i always thought it only fakes the mtab entry
<infinity> The only thing lazy does is allow you to keep files open.
<ogra_> or rather the removal
<infinity> I blame all this GUI auto-mounting crap for the race, if I had to point fingers randomly.
<infinity> Every 15th run of this loop or so, I get a folder window popping up.
<infinity> If that process is opening/scanning files on the FS when we're trying to umount it.  Boom.
<ogra_> at that point the partition should already be labeled in a way it doesnt get mounted
<ogra_> so it shouldnt automount on the installed system
<infinity> Oh, this would be because we haven't fixed jasper to change the label yet. :P
<infinity> Or hadn't on the system I'm testing on.
<ogra_> yeah
<ogra_> thats the main reason for the label :)
<infinity> Is that fixed now?
 * ogra_ checks
<infinity> I'd say no.
<infinity> Since the latest change in bzr is my GROWROOT fix.
<infinity> Why that's in all-caps, I don't know.  I need coffee.
<ogra_> heh
<ogra_> infinity, janimo worked on that but mx5 got in the way i think
 * ogra_ gets some icecream
<infinity> I'll fix the label thing today, then.
<ogra_> thx
<ogra_> shouldnt be to hard, ask janimo thogh, he probably has some code already
<infinity> I think he got sidetracked by shiny.
<ogra_> i know he looked into mtools stuff for it
<ogra_> yep
<infinity> But it's easy to set a label.
<ogra_> well, it needs hook additions for mtools etc
 * GrueMaster tests that theory.
<ogra_> and possibly an mtoolsrc
<ogra_> in the initrd
<GrueMaster> Any way the partition can be labeled at image creation time?
<infinity> Yes, we did that, and Oliver told us we were bad people. :P
<ogra_> GrueMaster, then users wont see it (hint ... replacing u-boot/MLO)
<infinity> (Because then you can't easily mount it pre-install)
<infinity> Not that you can't mount it, mind you, just not easily.
<GrueMaster> Oh yea.  Right.  :(
<GrueMaster> Forgot that whole arguement.
<ogra_> i didnt say you were bad people !
<ogra_> just mildly bad
<infinity> -rwxr-xr-x 1 root root 51560 2011-08-20 14:36 /sbin/dosfslabel
<infinity> -rwxr-xr-x 1 root root 27472 2011-08-20 14:36 /sbin/mkdosfs
<infinity> Can someone explain to me why it takes more code to change a label than to create the filesystem? :P
<ogra_> hahaha
<GrueMaster> If the label is the cause, that would mean gvfs is running during oem-config.  Why would that need to be running?
<infinity> I'm not sure the label is the cause during oem-config.  I'm just suspecting it could be causing a race here that allows me to see the bug.
<infinity> Or, rather, to see the race and work around it. :P
<infinity> I intend to make f-k happy on this system first, then fix the label, not the other way around.
<ogra_> ++
<GrueMaster> Well, I am currently testing that theory.  Will know in a few minutes.
<ogra_> gvfs should definitely not run in ubiquity-dm
 * infinity does a test loop with s/sync && umount/umount -l/
<ogra_> might be though that it uses gnome-session for panel and the applets and it could be that gnome-session by default starts gvfs regardless
<infinity> If lazy works consistently, it's probably the more elegant solution for whatever races might bite us here.
<ogra_> yes
<infinity> T/win 48
<GrueMaster> sigh.  Label ENOFIX.
<infinity> Yeah.  Didn't think it would.  But it needs fixing anyway. :P
<ogra_> did you use the right label ?
<ogra_> :)
<ogra_> just to make sure
<GrueMaster> SERVICEV001
<ogra_> k
<GrueMaster> It made it disappear on my desktop.
<ogra_> yep
<ogra_> udev has that name hardcoded
<ogra_> err
<ogra_> udisks but in a udev rule
<infinity> Lazy seems to be doing the trick.
<GrueMaster> And syslog shows the same tmpmount busy error.
<ogra_> yeah
<ogra_> i dont think gvfs is the issue here
<ogra_> (and it seriously shouldnt run at all)
<GrueMaster> Oddly enough, I can reliably reproduce this issue on the SD cards given to us at the Dallas rally.
<ogra_> the cheapo but fast ones ?
<GrueMaster> Yea.  The red 16G micro center ones.
 * ogra_ needs to find his, i'll test with it tomorrow
<infinity> lLazy was good for 20 tries in a row, going for the longer loop and a smoke.
<ogra_> actually i need to call it a day to not be killed with a spoon by susie who waits with dinner ...
<ogra_> i'll do the TI icon stuff tomorrow and should beyond that have spare cycles if there is anything pressing left
<infinity> Indeed.  Go avoid spoon death.
<ogra_> so if there is anything leave me a ping or mail
 * ogra_ waves
<GrueMaster> Looking at jasper, I notice all of the logging lines (...>>${LOG} ) begin with $MYECHO, which means they go through plymouth.  Shouldn't they just be "echo ...>>${LOG}"?
<infinity> MYECHO isn't plymouth if we don't have it installed.
<infinity> MYECHO="echo "
<infinity> if [ -x /bin/plymouth ] && plymouth --ping; then MYECHO="plymouth message --text="
<infinity> fi
<infinity> Oh, wait.  Stuff for the log is in MYECHO?  Where?
<GrueMaster> Look further down at lines 83,84.
<infinity> Ahh, yes.
<infinity> That probably wants a tee or something.
<infinity> If busybox has tee.
<infinity> But I'm not going to mangle any of that today.
<infinity> This thing's fragile enough as it is. :P
<GrueMaster> 83 should be a $MYECHO.  Any line that ends with >>${LOG} should be just an echo, otherwise they will not show up in the logfile.
<GrueMaster> I think ogra_ did a s/echo/$MYECHO/g when he added plymouth support.
<infinity> Probably.
<infinity> Still, should replace it all with a tee function and just have the log reflect the console.
<GrueMaster> Tee won't work if pushing out to plymouth.
<infinity> I said a tee function, not tee itself.
<infinity> Something to multiplex between log and console/plymouth.
<infinity> Not terribly tough.
<infinity> But for now, I'll just fix some oopses.
<infinity> Only found two anyway.
<GrueMaster> Ugh.  I keep taking a screenshot of this ugly oem-config screen, and keep blasting the SD before saving it off.  sigh.
<GrueMaster> Testing to see if adding sync to flash-kernel fixes this issue.  I know it isn't a clean fix, but for now...
<GrueMaster> And since I can reliably reproduce this (6 for 6 times so far) on this SD, I can always revert to test a better fix.
<infinity> I've been testing lazy instead, if you'd like to test that.
<infinity> s/umount/umount -l/ to both umounts in f-k.
<infinity> A few hundred into my test, and I haven't been able to race it.
<GrueMaster> My fix doesn't show the error in the syslog anymore, but oem-config still fails.  Not sure why.  Back to combing useless output.
<janimo> infinity, ah dosfslabel. Seems much saner than using mtools
<janimo> did not know about it
<infinity> Yeah, already fixed.
<infinity> Well, when I do a round of testing here and commit.
<GrueMaster> infinity: Could this be it?  syslog: Sep 28 12:00:18 localhost ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
<infinity> Depends on if it's retrying.  But also, WTF.
<infinity> The only thing talking to and/or locking the debconf DB should be ubiquity itself.
<GrueMaster> Repeated 5 times according to the next line.
<infinity> Are these fresh installs, or are you restarting ubiquity after a failed attempt?
<GrueMaster> Reflashing SD before trying something new.
<GrueMaster> When oem-config reappears, I switch to alt-F1 and ctrl-alt-del.
<GrueMaster> I wish ubiquity would just log to its own file.  having it output to syslog is very messy.
<GrueMaster> sigh.  Guess I start yet again and enable oem-config debug.
<GrueMaster> After lunch.
<GrueMaster> Gaaah!  Forgot to save the screenshot off the SD before reflashing...again.  sigh.
<infinity> Ugh.  One small bathroom break, and I've completely lost my train of thought.
<GrueMaster> Kind of a pisser, isn't it?  :P
<infinity> Yeah.  I need to stop this getting old business.
 * infinity breaks from ARM stuff to do some release managling and clear his head.
 * GrueMaster takes yet another screenshot.  sigh.
<skaet> ogra_,  can you confirm,  ac100 and mx5 are both to be considered community projects, with no official support, and you'll be the signoff?
 * skaet is doing some manifest scrubbing.
<ppisati> rsalveti: did you test the kernel? if not, it's here: http://people.canonical.com/~ppisati/linux-image-3.0.0-1205-omap4_3.0.0-1205.11_armel.deb
<infinity> skaet: That sounds right to me.
<skaet> thanks infinity,  I'll go with that for now then.
<rsalveti> ppisati: not yet, but will test now, we just fixed the issue we were having at linaro today
<ppisati> rsalveti: ok, no prob
<ppisati> rsalveti: i'm here
<infinity> Sweet mother of creepy gah.  I haven't done a fresh install on a machine with a webcam since that ubiquity changes.  It turns it on and offers to take my picture during install?
<infinity> That's just wrong.
<infinity> (On the flipside, "hey, the ac100 webcam works")
<GrueMaster> Heh.
<davidm> skaet, you are correct on ac100 and imx5x no support, considered to be community
<infinity> Oh, balls.  ac100 needs the same fix I gave omap and mx5 two days ago.
<gildean> at least the ac100 community is quite active
<skaet> davidm,  thanks.
<davidm> skaet, trying to pay attention as I can today
<GrueMaster> infinity: So, making oem-config start with --debug only succedes in generating 10x the logging of useless info.  As an added bonus, oem-config now crashes, butthat info must be confidential as there is no sign of it crashing in syslog, dmesg, oem-config.log, installer/dm or anywhere else I look.
 * GrueMaster is tempted to just file a critical bug against ubiquity, attach all the logs, and let the installer dev's figure out the whole mess.
<infinity> I wish I could reproduce it...
<infinity> Though I haven
<infinity> Err.
<infinity> I haven't reinstalled my Panda today, so maybe a surprise is in store.
<infinity> The ac100 went flawlessly though (except for my needing to give it oem-config-gtk)
<ppisati> rsalveti: i
<ppisati> 'm leaving
<ppisati> can you give it a boot?
<rsalveti> ppisati: slacker :P
<rsalveti> ppisati: do you need to send the pull request today?
<ppisati> yep
<ppisati> tomorrow is final freeze
<rsalveti> great, give me 30 min
<ppisati> ok
<rsalveti> ppisati: we'll also need a FFe for u-boot-linaro
<rsalveti> ogra_: jcrigby: ^
<rsalveti> for 4460 support, as I said before
<GrueMaster> ppisati: If it helps, I had booted it on my system earlier today (before I got sucked into daily image hell).
<ppisati> GrueMaster: panda Ax?
<rsalveti> if it booted fine at 4430 is already a start
<GrueMaster> A3
<ppisati> yep, but we are pull requesting for 4460
<ppisati> without it, i'm not sending the req
<GrueMaster> Right.  I just wanted to make sure nothing got broken in between.  :P
<ppisati> yep
<ppisati> thanks for testing
<GrueMaster> rsalveti: Will the next u-boot fix ES2.0 support?
<rsalveti> GrueMaster: yes
<GrueMaster> excellent.
<ndec|home> ppisati: i think you need the pull request even without 4460. since we are fixing some graphics and MM stuff as well.
<rsalveti> ppisati: can you point me the git tree for this deb?
<ppisati> rsalveti: wait
<ppisati> rsalveti: git://kernel.ubuntu.com/ppisati/ubuntu-oneiric.git ti-omap4
<rsalveti> ppisati: thanks
<ppisati> and here is the deb
<ppisati> http://people.canonical.com/~ppisati/linux-image-3.0.0-1205-omap4_3.0.0-1205.11_armel.deb
<Gottox> hi there :)
<jcrigby> rsalveti, so u-boot for this is 2011.09.2 which has been tested with Linaro for a few days
<jcrigby> ?
<rsalveti> jcrigby: yes, latest one we're also using
<jcrigby> ok, do I wait for a confirmed status ffe?
<rsalveti> guess we can use the other FFe bug we have around already
<rsalveti> jcrigby: yes, I'll comment on that bug
<jcrigby> ok, just going to say someone important needs to set status to confirmed:)
<Gottox> I get an error when using rootstock: http://pastebin.com/cx03qteT
<rsalveti> jcrigby: yes :-)
<rsalveti> GrueMaster: can you help us testing pxe with this latest u-boot?
<rsalveti> jcrigby tested already, but would be good to check with it first
<GrueMaster> Sure, I guess.  What platforms?  Just panda?
<rsalveti> GrueMaster: https://launchpad.net/~linaro-maintainers/+archive/overlay/+files/u-boot-linaro-omap4-panda_2011.09%2B5353%2B35%2B201109262044~natty1_armel.deb
<rsalveti> in theory there's usb support at xM too, but we didn't test it yet
<rsalveti> wget https://launchpad.net/~linaro-maintainers/+archive/overlay/+files/u-boot-linaro-omap3-beagle_2011.09%2B5353%2B35%2B201109262044~natty1_armel.deb
<rsalveti> jcrigby: GrueMaster: ppisati: bug 851974
<ubot2> Launchpad bug 851974 in u-boot-linaro "FFe: u-boot-linaro 11.09, misc fixes for new silicon and boards" [Undecided,New] https://launchpad.net/bugs/851974
<rsalveti> GrueMaster: please let us know when you're able to test these packages, making sure PXE is still working is the most important thing
<rsalveti> once the test is done I'll request the release team to review it
<GrueMaster> On it now.
<infinity> Well, 1000 passes of flash-kernel with lazy umounting, I'll call that good.
<GrueMaster> infinity: Good.  Now see why oem-config is recycling on the daily omap4.
<infinity> Booting that in a bit.
<GrueMaster> rsalveti: jcrigby  What on pxe has changed in this u-boot?
<infinity> Well, flashing it now.
<jcrigby> GrueMaster, it should be identical
<GrueMaster> Ok, so just a no-frills sanity check then.  Got it.
<jcrigby> GrueMaster, make sure the naming of uuid/macaddr based downloads is not broken
<rsalveti> GrueMaster: yeah, just to check if we didn't break anything
<GrueMaster> ok.  I'll throw it into the pool.
<GrueMaster> jcrigby: spl: error reading image u-boot.img, err - -1
<GrueMaster> What happened to using u-boot.bin?
<GrueMaster> This will break our images if it doesn't support u-boot.bin.
<rsalveti> GrueMaster: in theory it should support it same way as before
<rsalveti> let me wait jcrigby to answer that
<rsalveti> GrueMaster: did you replace both MLO and u-boot.bin?
<GrueMaster> My process is to reformat mmcblk0p1, copy MLO & u-boot.bin (in that order) and reboot.  Everything else it pulls from tftp.
<rsalveti> GrueMaster: great
<jcrigby> rsalveti, I knew something was wrong
<GrueMaster> It's the day before final freeze.  What wouldn't be wrong?
<GrueMaster> :P
<jcrigby> I reverted the .bin support in 09 before I found that the real problem was the spl size issue
<rsalveti> jcrigby: :-)
<jcrigby> but now that the spl size issue is fixed the .bin support can be put back in
<GrueMaster> Why the switch to img in the first place?
<jcrigby> the new spl loads .img by default
<jcrigby> it could load a uImage forexample
<jcrigby> u-boot upstream sometimes forgets about backward compatibility
<jcrigby> at least on arm platforms
<GrueMaster> Well, at least it matches the hardware.  :P
<jcrigby> ok, I'm needed at a school meeting with my kids right now
<jcrigby> when I get back can I push a fix to ppa
<jcrigby> then test
<jcrigby> then push to archive if ppa test works out ok?
<jcrigby> bbl
<GrueMaster> Also, no tftp/pxe support on beagleXM.  usb start initiallizes the usb, but tftpboot reports no network devices.
 * GrueMaster takes a break for a bit.
<rsalveti> GrueMaster: ok, thanks
<rsalveti> jcrigby: will provide a new u-boot for GrueMaster while you're away
<rsalveti> with this fix
<rsalveti> GrueMaster: http://people.linaro.org/~rsalveti/u-boot/
<rsalveti> the same one from the package I sent + u-boot.bin compatibility
<GrueMaster> Bah.  Broken.
<GrueMaster> At least it loads uboot.bin now.
<GrueMaster> Hmm.  Doesn't like my pxelinux.cfg
<GrueMaster> Let me double check on another system.
<GrueMaster> rsalveti: The old version on http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-armel/current/images/omap4/netboot/ works fine with my pxelinux.cfg.  This one does not.
<rsalveti> hm, then it could be a bug at the pxe implementation
<rsalveti> GrueMaster: what error are you getting?
<GrueMaster> One sec.
<GrueMaster> I get "Ignoring malformed menu command:  label" then dumped to u-boot prompt.  The message is the same on the working version, but it goes forward ok.
<GrueMaster> My pxelinux.cfg is http://paste.ubuntu.com/698765/
<rsalveti> hm, ok, need to check the changes between both versions
<rsalveti> and why this ignoring message
<GrueMaster> The ignoring message could be my config.  It has been eons (2001) since I did pxelinux stuff.
<GrueMaster> Well, I fixed the label error in my config, but it still fails to run.  I now get this:
<GrueMaster> Bytes transferred = 740 (2e4 hex)
<GrueMaster> Config file found
<GrueMaster> And a prompt.
<rsalveti> GrueMaster: and you paste your new config? going to give it a try here
<rsalveti> GrueMaster: ppisati kernel worked fine here at my 4460 es1.1
<GrueMaster> http://paste.ubuntu.com/698777/
<rsalveti> but he's not on-line anymore, let me sms him
<GrueMaster> It is 00:38 his time.
<GrueMaster> You told him 30 minutes, 90 minutes ago.
<GrueMaster> oops.
<rsalveti> would help if he said he was going to leave :-)
<GrueMaster> [14:10:20] <ppisati> rsalveti: i
<GrueMaster> [14:10:32] <ppisati> 'm leaving
<GrueMaster> like that?
<rsalveti> hm, where, didn't see it
<rsalveti> I think I just saw 'i' and that was it
<rsalveti> :-)
<GrueMaster> Just before you said:  [14:10:42] <rsalveti> ppisati: slacker :P
<GrueMaster> That was just before we got into this u-boot testing.
<GrueMaster> It's all in the scrollback.  :P
<rsalveti> oh, but that was almost 2 hours ago
<GrueMaster> At any rate, I need to break for a bit.  My eyes are gettng buggy.
<rsalveti> yeah, release is still killing me
<GrueMaster> Same here.  I am severely bogged down by issues in the desktop image that apparently didn't get looked at since I filed them...In Alpha.
<rsalveti> heehe... fun
<rsalveti> GrueMaster: yeah, pxe boot does nothing
<rsalveti> hm, weird, it works fine with my pxe config
<rsalveti> hm, but got: ERROR: Did not find a cmdline Flattened Device Tree
<jhobbs> rsalveti: is fdt_addr set in your env?
<rsalveti> jhobbs: yes
<rsalveti> jhobbs: GrueMaster: without a default entry pxe boot does nothing
<rsalveti> is it really required?
<rsalveti> GrueMaster: http://paste.ubuntu.com/698795/
<rsalveti> GrueMaster: works only when I set the default argument
<rsalveti> let me compare u-boot-linaro 11.08 and 11.09, at least the pxe patches
<rsalveti> hm, 11.09 is using a new patchset
<rsalveti> jhobbs: when removing fdt_addr it worked fine
<jhobbs> do you have a fdt blob at fdt_addr?
<rsalveti> no, I'm not loading it
<rsalveti> I was trying an menu option that didn't load the dt file
<rsalveti> but as fdt_addr was set at my env, I could not boot it
<jhobbs> i'm not sure what menu you're referring to there, the pxe code doesn't load fdt's itself
<GrueMaster> rsalveti: It worked on the old release, and it matches https://help.ubuntu.com/community/PXEInstallServer fairly closely.
<rsalveti> GrueMaster: yup, this is probably a bug
<rsalveti> jhobbs: fdt_addr is always set at our u-boot
<rsalveti> but we don't always need a blob
<rsalveti> that's why at the cases we are not loading it, it fails
<jhobbs> i see - the pxe code assumes that if fdt_addr is defined a fdt blob is being used and tells bootm that
<jhobbs> it could be smarter and check that something is actually present there
<rsalveti> yeah
<rsalveti> jhobbs: any idea why without a 'default' entry pxe boot does nothing?
<rsalveti> probably a bug at the parsing code
<rsalveti> wasn't the case at the previous patch set
<jhobbs> rsalveti, i'm not sure - i will check
<jhobbs> what behavior were you seeing with the last patch set?
<rsalveti> jhobbs: http://paste.ubuntu.com/698795/ example of a pxeconfig file
<rsalveti> this works fine
<rsalveti> if we remove the first line, the default entry, pxe boot gets me back to the prompt
<rsalveti> without saying a word
<rsalveti> jhobbs: http://paste.ubuntu.com/698802/
<jhobbs> ok, i'm building to test right now
<rsalveti> menu_create is returning NULL
<jhobbs> hmm what i'm seeing is that it's trying to boot the default label but there is no default label specified
<jhobbs> so menu_get_choice is returning -ENOENT
<jhobbs> http://paste.ubuntu.com/698810/
<jhobbs> whitespace will be messed up but that should get you that error message
<rsalveti> jhobbs: menu_create gets called with cfg->title == NULL
<rsalveti> then it returns NULL at menu_create
<rsalveti> because it'll try to call malloc with sizeof null
<rsalveti> let me check
<rsalveti> >> menu_create:372
<rsalveti> title: <NULL>, timeout: 0, prompt: 0
<rsalveti> >> destroy_pxe_menu:1196
<rsalveti> hm, doesn't seems to be the issue
#ubuntu-arm 2011-09-29
<rsalveti> read it wrong here
<infinity> NCommander: Pokity poke.
<jhobbs> i think i know what is wrong - in older versions, when it looked for a default and didn't find it, it would go ahead and attempt to boot labels it hadn't tried to boot yet
<rsalveti> jhobbs: yup, makes sense
<infinity> NCommander: I need someone with ~ubuntu-installer commit access who happens to be in my timezone.  Wake up! ;)
<jhobbs> rsalveti: i have a patch that fixes that now, i just need to run through a few tests
<jhobbs> rsalveti: should i email it to you?
<rsalveti> jhobbs: please, rsalveti@linaro.org
<jhobbs> ok
<jhobbs> ok it's sent
<jhobbs> rsalveti: let me know if you have troubles with it. the fdt_addr issue isn't as straightforward - i'm not sure check for an fdt there is the right answer either, it may be that the pxe command should look for explicit instruction to use fdt, like bootm does
<rsalveti> jhobbs: yeah, probably
<rsalveti> let me check your patch
<infinity> GrueMaster: So, I can't make oem-config crash here at all.  Which makes it pretty painful to figure out what's going on for you.  But every other issue raised today (partition label, flash-kernel race, ac100 not removing oem-config) should be fixed in tonight's dailies, the only remaining one is the slideshow, which should be fixed by a pending merge I have to ubiquity.
<infinity> GrueMaster: (You can kick your roommate to merge my ubiquity fix, since he's in ~ubuntu-installer) :P
<jhobbs> rsalveti: i'm going offline and might not check irc until tomorrow, email me if there are issues, thanks for your help
<rsalveti> jhobbs: sure, thank you :-)
<rsalveti> jhobbs: worked fine now
<rsalveti> GrueMaster: http://people.linaro.org/~rsalveti/u-boot/
<rsalveti> GrueMaster: the fixed u-boot for pxe
<rsalveti> jcrigby: with the patches available at http://people.linaro.org/~rsalveti/u-boot/ pxe works fine again
<rsalveti> infinity: http://s3.amazonaws.com/imgly_production/2114800/large.jpg
<rsalveti> libjpeg-turbo and libjpeg
<rsalveti> running on imx53
<rsalveti> tgall_foo should have the details
<infinity> rsalveti: Very cool.
<GrueMaster> rsalveti: u-boot appears to work correctly again.  Let me know when it is in the pool for more official testing.
<rsalveti> GrueMaster: great, thanks for testing it
<GrueMaster> infinity: Daily build just failed.  May be a while before I will be able to test your changes.
<infinity> GrueMaster: Neat trick, since the daily builds don't happen for another 43 minutes...
<infinity> cdimage@antimony:~$ crontab -l | grep ' ubuntu daily-preinstalled' && date
<infinity> 55 1 * * *	buildlive ubuntu daily-preinstalled && for-project ubuntu cron.daily-preinstalled
<infinity> Thu Sep 29 01:09:12 UTC 2011
<jcrigby> rsalveti, /me the slacker has finally returned
<rsalveti> jcrigby: hey :-)
<jcrigby> rsalveti, thanks for filling in for me, I owe you as always
<rsalveti> jcrigby: just need to check if the removal of fdt is the right thing to do
<rsalveti> not yet sure why it was added
<jcrigby> the old patch set used different names for kernel and ramdisk addresses, when converting to the new patchset the names had changed to ones used elsewhere in u-boot and documented in README.  So while adding this names to the panda config I added the other standard name/address for fdt
<jcrigby> had not idea that it broke anything
<jcrigby> rsalveti, so since I added it just for completeness sake he are probably ok deleting it at least for this ubuntu release
<jcrigby> s/he/we
<rsalveti> jcrigby: I think so
<rsalveti> as this will just affect the default behavior
<jcrigby> yes
<rsalveti> if the user wants to use fdt, he can set that at boot.src
<jcrigby> yes
<jcrigby> rsalveti, two recipe driven builds are going right now.  Also I have a source package ready for putting.  Do I need to wait for something.  Last time I did this I thought I learned that someone was supposed to set status to confirmed to indicate approval for the ffe.
<rsalveti> jcrigby: let's wait the new builds to be available, then request GrueMaster to give some testing and then we request the release team to accept the FFe
<jcrigby> rsalveti, ok sounds good
<rsalveti> jcrigby: only thing is that the final freeze is tomorrow
<jcrigby> I understand
<rsalveti> so I guess I'll add a comment there now...
<rsalveti> jcrigby: did you set CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS ?
<jcrigby> no, I guess I get to do one more release
<rsalveti> jcrigby: bug 837235
<ubot2> Launchpad bug 837235 in u-boot-linaro "Broken ES2.0 support at U-boot-linaro 11.08" [Medium,Confirmed] https://launchpad.net/bugs/837235
<jcrigby> ok
<rsalveti> jcrigby: sorry for giving you more work
<jcrigby> its not a problem
<rsalveti> but getting a FFe and not fixing es2.0 will upset some people for sure
<jcrigby> right
<jcrigby> It has the added plus of reducing spl size
<jcrigby> a patch hit u-boot ml today setting this as default and setting spl limit back to 32K
<rsalveti> jcrigby: cool
<rsalveti> jcrigby: did you fire up another build already?
<rsalveti> at the package recipe
<jcrigby> yes
<rsalveti> jcrigby: great
<jcrigby> https://code.launchpad.net/~linaro-maintainers/+archive/staging-overlay/+build/2813063
<infinity> GrueMaster: Nevermind, no new images because ubiquity was FTBFS on i386.  Yay for skew the other direction for once. :P
<infinity> GrueMaster: If I'm up late, I might re-spin some armel images for testing.
<sniperjo_> Hi guys, I'm trying to boot my board but it stops at uncompressing kernel â¦ I've checked my serial line is setup properly in uboot and there is no boot.src
<twb> sniperjo_: it might be working but just not printing anything
<twb> That line comes from the bootloader; you then need to tell the kernel where console= to put it
<sniperjo_> twb: where can i do that ?
<twb> It's args passed to the kernel
<twb> e.g. qemu-system-arm -nographic -M versatilepb -kernel vmlinuz-3.0.0-1-versatile -initrd initrd.gz -append 'console=ttyS0 console=tty0 console=ttyAMA0,38400n8'
<sniperjo_> in uboot i have setenv linux_args setenv bootargs console=${console} nfsroot=${serverip}:/dev/mmcblk0p2 ip=${ipaddr}:${serverip}:192.168.1.254:255.255.255.0::eth0:off; tftpboot 84000000 uImage; run linux_args; bootm 84000000;
<infinity> sniperjo_: And what is console set to?
<sniperjo_> console=ttyS2,115200n8
<infinity> Your board actually has a device called ttyS2?
<sniperjo_> yes, its the console thats used when i boot in angstrom
<infinity> Potentially renamed in later kernels.
<infinity> Though just a shot in the dark.  It could just as easily be the kernel just not booting too. :P
<sniperjo_> infinity: by the way in still o n2.6.32, do i need to update my host computer
<infinity> Update your "host"?
<sniperjo_> The annoying thing is/.. somewhere, one of the things i have done, I've got to " Uncompressing kernelâ¦. done" and I've just read somewhere that sometimes thats because its set up or a guy enviroment
<sniperjo_> as in, what i used to compile the kernel
<infinity> If you're using Angstrom sources, I'd recommend using whatever toolchain they recommend (ie: I don't know).
<infinity> For something closer to upstream or Linaro sources, the latest and shiniest oneiric would be saner.
<sniperjo_> i really don't want to use angstrom
<sniperjo_> so in that case i do need to update?
<infinity> I'm not even sure what device you're using...
<infinity> But if there are newer kernels out there that support it, that would be a good place to start.
<sniperjo_> infinity: an atom netbook
<infinity> ...
<infinity> I mean your ARM device.
<sniperjo_> ah, technexion tsunami, omap4540, 25mb ram
<infinity> ...
<sniperjo_> whoopsâ¦ 3530
<infinity> You're trying to run Ubuntu on a pseudo-embedded system?
<sniperjo_> 256mb ramâ¦ unless I've got some crazy prototype
<infinity> Oh, 256 sounds less painful. :P
<infinity> I'm going to guess that our "omap" kernel is too Beagle-specific to work on it, eh? :/
<infinity> But, our omap sources, with the Angstrom .config shoved at it, might Just Work.
<sniperjo_> yeah, it dies straight away, not the same vendor id
<infinity> And for that, I'd definitely recommend compiling from an oneiric system, yes.
<infinity> Kernel shouldn't be checking vendor id at all.  You mean our images do that (as in, our uBoot)?
<infinity> I'm saying you could try our kernel with their uBoot.
<infinity> But it's probably still missing some device support, since it's fairly Beagle-ish.
<sniperjo_> infinity: I've defiantly tried it, and it definitely didn't work
<infinity> Either way, it's 2am, I should probably not be trying to be helpful, and go to bed.
<infinity> But some shiny newish linaro omap sources with the .config from your Angstrom kernel, built with an oneiric toolchain, may well work.
<sniperjo_> ok, so i need to update my "host to one irc" and try and compile again
 * ogra_ hugs infinity, thanks for the installer quietening
<infinity> ogra_: NP.  It was annoying me in testing.  Sadly, no new images today with all my fixes yesterday, since ubiquity's FTBFS on x86. :/
<infinity> ogra_: Yay for archive skew in the other direction for once?
<ogra_> infinity, well, skew is skew :)
<Guest18959> hi!
<ogra_> hey zumbi
<zumbi> hi
<zumbi> ogra_: could you pull dietlibc from debian/experimental for oneiric?
 * ogra_ can try ... we have final freeze today :)
<zumbi> ogra_: it currently ftbfs on *buntu
<zumbi> but experimental should have the fixes
<zumbi> to have a working version, at least it works on debian armel/armhf
<ogra_> infinity, can you sync that ? or do i need a bug etc etc
<zumbi> I told doko but he seem to have missed it
<ogra_> very likely, i think he is really overworked
<zumbi> sure
<zumbi> ogra_: thanks
<ppisati> GrueMaster: yesterday, weren't you suggesting that the problem with the verbose audio messages on console were due to a driver rename? s/SDP4430/Panda/?
<rsalveti> ppisati: it is, because then the current ucm files are useless after this change
<ogra_> ppisati, i hope that fix got in in todays build ?
<ogra_> else we will have lost sound again
<ppisati> which fix?
<ogra_> s/SDP4430/Panda/
<ppisati> well, i did the rename
<ogra_> good
<ppisati> no wait
<ppisati> i'm using the jack on the back of my panda board
<ogra_> as long as alsactl finds the right name all is fine
<ppisati> and i always had audio
<ogra_> the renaming only happened recently in andys branch i think
<ppisati> the rename was just to silence the messages on console
<ogra_> no
<ogra_> all alsa settings fully depend on the name
<ppisati> so i shouldn't have audio, right?
<ppisati> but i have it
<ppisati> not hdmi, using the lower audio jack
<ogra_> with the recent images and the new kernel ?
<ogra_> i.e. on a fresh install where alsactl didnt create the defaults yet
<ppisati> yes
<ppisati> ah
<ppisati> where does it store the config? i mean alsa
<ogra_> its tricky to get rid of it
<ppisati> doh
<ogra_> best is to take the SD in your PC and remove /var/lib/alsa/asound.state
<ogra_> *best
<ppisati> ok
<ppisati> i'll try
<ogra_> (it gets recreated on every shutdown, so its not easy to do it on a running system without hacking around in upstart jobs and udev rules)
<ppisati> single user and i axe it
<ppisati> btw
<ppisati> to check the renaming: /proc/asound/cards should be equal to 2.6.38.xx, right?
<ogra_> yep
<ppisati> ok
<ppisati> btw, i thgought fix could go in even after final freeze
<ppisati> or maybe not?
<ogra_> sure
<ppisati> ah ok
<ogra_> but we still havent had much testing for the sound stuff
<ogra_> so the earlier the better
<ppisati> ok ok
<ppisati> axe alsa state
<ppisati> test again
<ppisati> if not working, apply the rename and retest
<ogra_> would be our first release where sound works on release day
<ppisati> :)
<ndec> ogra_: i don't want to be pessimistic... but i don't have audio... granted that I am not using your kernel, but I am using the kernel which was used by ppisati to make the ubuntu kernel...
<ogra_> hmm
<ogra_> well, lets see what paolos test turns out now
<ogra_> testing with an existing state file is indeed kind of moot
 * diwic has not understood why we need this UCM thing in the first place, whereas one could write a PulseAudio profile instead to do the same thing.
<ndec> UCM was supposed to help ;-)
<ogra_> diwic, i think the idea was to use both
<ndec> ogra_: on one panda that I have dist-upgraded since alpha2, audio works fine ;-)
<ogra_> hmm
<diwic> ogra_, no, PulseAudio profiles/paths, and UCM, are overlapping concepts.
<ogra_> so should we roll back to the kernel we had at A2 ?
<ogra_> :)
<ndec> if we use our images from yesterday evening + our kernel --> no audio
<ndec> ;-)
<ogra_> ndec, iirc that was the natty kernel still
<ndec> here we go...
<ndec> it's even easier to find in the archive!
<ndec> for UCM to work, we need to have /usr/share/alsa/ucm/Panda/Panda.conf, is that correct?
<ogra_> i think so
<jcrigby> ogra_, I'm ready to push the final u-boot source once someone approves
<ogra_> oh, go ahead
<jcrigby> oh, ok
<ogra_> i'll do the paperwork in a minute on the bug
<ndec> ogra_: did you submit the change (s/SDP4430/Panda/) to alsa?
<ogra_> ndec, i think diwic added it in an SRU
<ndec> ogra_: can you send me (again) the link with the queue of packages waiting for entering in the archive?
 * diwic does not remember changing "SDP4430" to "Panda".
<ndec> rsalveti: ogra_: ^^ if we change the device name in the kernel and not in alsa, we might be in troubles..
<ppisati> ok, after deleting the
<rsalveti> yup
<GrueMaster> ndec: I have the latest alsa source..  I find no reference to "Panda" there.  It is all ADP4430.
<ppisati> /var/lib/alsa/asound.state file and rebooting
<ppisati> we have the unfamous "pulseaudio go nuts and swamp the console with lo messages" and 100% cpu usage for this
<ppisati> renaming the driver s/Panda/SDP4430/ we get back to a "normal" logging on console
<ppisati> nut no audio :(
<ppisati> but
<GrueMaster> ppisati: Hence why I filed it as a kernel bug originally.  While the messages are directly from Pulseaudio, it is because of a kernel change.
<ppisati> GrueMaster: ok, so i can shove the driver name change in, but still there's some alsa tweaking to do
<ppisati> else we won't have audio after a fresh install
<ppisati> alt!!!
<ppisati> the volume was low
<ppisati> @#$#@$
<ppisati> we have audio! :)
<GrueMaster> A fresh install should just work.  In my earlier test, renaming SDP4430 in all of the ucm files and rebooting worked fine.
<ppisati> yes, we haz it
<GrueMaster> Cool.
<ppisati> ok, let me commit it then
<ndec> GrueMaster: ? there is already SDP4430 in all UCM files.
<GrueMaster> The change to Panda is not in the upstream alsa git tree, so I don't know where it came from.
<GrueMaster> ndec, right.  Not sure where the rename to Panda came from.
<GrueMaster> I only did that as a quick experiment to see why it wasn't working.
<GrueMaster> UCM shouldn't have changed since Natty.
<ppisati> didn't we have an omap4 audio lp bug?
<ppisati> crap, can't find it...
<sniperjo_> I've followed a tutorial for getting ubuntu on my board ,I've set ups tftp server and such so it downloads the kernel and rootfs , it stop at  "uncompressingâ¦booting kernel ".. from google lots of people have that because their console isn't set right, but my bootargs use ${console} which works when the prebuilt sdcard is in there
<GrueMaster> ppisati: bug 820466
<ubot2> Launchpad bug 820466 in linux-ti-omap4 "No sound on omap4 pandaboard" [High,Fix released] https://launchpad.net/bugs/820466
<ndec> ogra_: ppisati: diwic: if i rename all the SDP4430 to Panda in /usr/share/alsa/ucm, sound is working with a kernel that calls the sound card Panda
<GrueMaster> ndec: Upstream alsa still names it SDP4430.
<ndec> this is for the Blaze board
<GrueMaster> And changing the kernel name is easier (one line if I read the driver correctly).
<ndec> are you sure it's upstream btw?
<ndec> but wrong...
<doko> diwic, I'll upload your openjdk/pulseaudio arm fix, just with a cast to jlong instead
<ndec> i meant easier but wrong. the real name in the kernel should be Panda
<GrueMaster> ndec: I have the alsa-project git tree here and up-to-date.
<GrueMaster> Why?  Is it different from platform to platform?
<ndec> yes
<ndec> GrueMaster: where in alsa upstream did they put the conf files?
<GrueMaster> I haven't seen any alsaucm files upstream yet, but they may be in a git tree I don't have yet.
<GrueMaster> Will check after the meeting.  #ubuntu-meeting.
 * ppisati refrains from commiting anything then...
<GrueMaster> ndec: Since we have freeze today, it makes more sense to fixe the one line in the kernel than the multiple ucm files.  If TI wants it renamed to Panda, we can do it next cycle, but we will need to know way before freeze.
<infinity> GrueMaster: I'd rather build alsa than another kernel.
<infinity> To be fair...
<GrueMaster> Really?  Alsa is a bit more intrusive.  Kernel is a separate tree affecting only omap4.
<infinity> There's nothing intrusive about s/SDP4430/Panda/ unless you have a sound card called SDP4430 on your amd64 machine.
<GrueMaster> No, but the packages are arch all.
<infinity> That doesn't make the fix any scarier.
<GrueMaster> On the kernel, it is a single line.
<infinity> It's one line in alsa if I do it with sed in debian/rules instead of a patch.  (which I wouldn't do, but my point is that, conceptually, this isn't a large or unreviewable change).
<infinity> And alsa is much faster to build/test.  And the fix belongs in userspace anyway, we'll have to do this all over again in 2 weeks if we don't do it now.
<infinity> (Or forget for 3/4 of the cycle and whine at the end that sound doesn't work, and argue again)
<GrueMaster> infinity: I don't trust it.  Remember, ext4 is a simple change too.  Right now I want the quick fix.  Since we have to rebuild the kernel anyways.
<GrueMaster> The "correct" thing to do is fix it upstream.  Since alsa doesn't know about "Panda", this has not been done.  Alsa does know about the SDP4430 though.
<ndec> GrueMaster: can you point me to where SDP4430 is reference in upstream alsa?
<infinity> GrueMaster: ext4 was a simple change.  It landed at the same time as a bunch of mx5 stuff that make people blame ext4 for other breakages though. :P
<GrueMaster> infinity: It wasn't a simple change as it required a bunch of jasper changes before we had working images.
<infinity> See above.
<infinity> And, for the record, SDP4430 isn't upstream in alsa at all.
<infinity> It's a local patch.
<ogra_> there were mx5 changes *and* a completely new image type (ac100) *and* ext4 at the same time
<infinity> We fix it in our packages, we're done.
<GrueMaster> ndec: I would, but the alsa-project gitweb interface seems to be broken.  The tree is git://git.alsa-project.org/alsa-kernel.git and the file is soc/omap/sdp4430.c
<ogra_> if you want to blame anything, blame ac100, that caused the most intrusive changes
<infinity> Oh, you're talking driver filenames?  That's meaningless.
<infinity> It's only the UCM stuff that needs fixing.
<ogra_> yeah, the filename doesnt matter, only whats in /proc/asound/cards
<ndec> GrueMaster: in this file you will find this:
<ndec>    if (machine_is_omap_4430sdp())
<ndec>         snd_soc_sdp4430.name = "SDP4430";
<ndec>     else if (machine_is_omap4_panda())
<ndec>         snd_soc_sdp4430.name = "Panda";
<ndec> ;-)
<ogra_> yes, SDP4430 used to be for the blaze
<ogra_> (and probably still is, i havent seen a recent blaze)
<ndec> what I copy/pasted is where we are doing the device name, e.g. what ends up in /proc/sounds/cards, and what is used by alsaucm config file
<GrueMaster> ndec: I just ran a git pull and didn't see it when grepping for Panda.
<ogra_> right
<ndec> GrueMaster: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=sound/soc/omap/sdp4430.c;h=424ca3d512f6b15c3f2318bbcd6644a77fd052ac;hb=ti-omap4
<GrueMaster> But just to err on the side of caution, I am recloning my tree.
<GrueMaster> ndec: That is our tree.  Not upstream.
<ndec> that will be upstream at some point.
<GrueMaster> And when did the addition of Panda get there?
<ndec> if we were using upstream stuff only, that wouldn't too nice...
<infinity> If we revert our omap4 kernel to vanilla, we may as well drop the subarch.
 * GrueMaster is getting tired of this argument.
<Neko> you can't drop the subarch it will break flash-kernel
<GrueMaster> I really don't care what you guys do.  Just fix the thing.
<infinity> Yes.  In the time it's been happening, libasound could have been fixed, uploaded, and built.
<GrueMaster> Same with the kernel.  Bad argument.
<ndec> infinity: by the way, don't rename the files from SDP4430 to Panda, duplicate them. so that you get support for Panda and SDP4430 board
<GrueMaster> Bug was filed a while ago.  If I had been doing daily testing instead of server testing, I would have been all over this weeks ago.
<infinity> ndec: That was the plan.
 * ndec remembers you talked about sed ;-)
<infinity> ndec: Was an example. :)
<ppisati> so you are going to fix in user space, right?
<ppisati> *fix it
<infinity> GrueMaster: 26 minutes versus 9 hours seems to support what I said.  But whatever.
<infinity> ppisati: That's where the fix belongs.  I see no point kludging it.
<ndec> GrueMaster: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commit;h=14a8827efa05606e7d8776d11ad2e030c12d427c
<ppisati> ok
<ndec> it's signed-off by liam. a good sign that it might end up upstream
<festhead> hi! Question: is it able yet to set the screen resolution on latest ubuntu?
<festhead> on pandaboard
<festhead> :)
<Neko> I second that question :D
<ndec> festhead: yes. at least on all the screens i have seen...
<ndec> it picked the largest one at boot.
<festhead> and where do you get the options?
<ndec> now if you want to change the resolution, you need support for XRandR in the driver, so you need to install our DDK driver from the TI PPA
<ndec> and it works too.
<ndec> it just pick the bigger resolution supported by the screen. no option.
<ogra_> well, you can force a resolution on kernel cmdline, no ?
<ogra_> was that dropped ?
<ndec> can you?
<Neko> ogra_, seems so, nothing I tried worked there.. it just keeled back over to 640x480
<ogra_> ndec, you could in the past, yeah, hdmimode= and friends
<ndec> ogra_: if you use the TI DDK driver yes you can using drm
<ogra_> indeed
 * ndec thinks that hdmimode has been removed
 * ogra_ isnt up to date with hacks :) 
<ogra_> and then i also have a proper monitor
<ndec> the good news is that the hack was removed in this case... in general we only add more hacks ;-)
<ogra_> so i wouldnt need such hacks
<ogra_> heh
<infinity> Yeah, I kind of get a giggle out of my Panda having the nicest monitor in the house.
<ndec> ogra_: infinity: i have to go... but i confirm that adding ucm/Panda fixed the audio issues on at least 2 different boards here...
<ndec> byw
<ndec> bye
<ogra_> infinity, upload away i'd say
<infinity> ndec: Yeah.  I'm testing and uploading within the hour.
<infinity> After I find coffee and a snack.
<GrueMaster> Don't forget udev will also need to be changed.
<GrueMaster> Possibly.
<infinity> GrueMaster: I should hope not.
<infinity> GrueMaster: This isn't about kernel driver names, it's about alsa device names.
<GrueMaster> infinity: There is a udev rule to load the alsaucm files.  I'll doublecheck to see how it is set up.
<GrueMaster> It is currently set to "ATTRS{id} =="SDP4430", RUN+="/usr/bin/alsaucm set _verb HiFi" and "ATTRS{id} =="SDP4430", RUN+="/usr/bin/alsaucm set _verb Record"
<GrueMaster> Not sure where ATTRS is set from, but I'm just saying heads up.
<infinity> So, entirely unrelated, but noticed in testing this.  "alsaucm set _verb Hifi" works great.  "alsaucm set _verb Record" fails.
<diwic> doko, xranby, ok, did both patches (pulseaudiodataline.patch and contextgetstate.patch) make it into openjdk-6 - 6b23~pre10-0ubuntu4 and did anybody actually test contextgetstate.patch ?
<ogra_> infinity, did you test with an mp3 player or the like ? mics dont work
<ogra_> infinity, its a real "line in"
<infinity> ogra_: No, I mean the command fails.
<ogra_> UH !
<ogra_> that should definitely not happen
<ogra_> bug it :)
<ogra_> playback is definitely more important and if that works i'm already happy
<GrueMaster> It would appear the PDM switch for AMIC no longer exists.  Looking to see if there is an alternative (renamed) control.
<ogra_> well, the HW doesnt support mics ... it probably just reflects the reality now
<GrueMaster> For now, commenting out the two lines makes alsaucm work.
<ogra_> (or does AMIC not mean analog microphone ?)
<GrueMaster> It supports audio in and that PDM enabled input.
<festhead> is it correct that is ubuntu 11.06 the ablility to change the resolution on a pandaboard is supported?
<GrueMaster> Like a mute button.
<ogra_> right, but only high level sources
<ogra_> festhead, there is no ubuntu 11.06
<festhead> great :P
<ogra_> there will be ubuntu 11.10 and there is 11.04
<festhead> and is it supported in 10.10?
<ogra_> well, it is supported by the closed driver in all releases afaik
<doko> diwic, contextgetstate.patch: did change the cast to jlong. no, the build would have taken too long. but imo it can't get worse
<ogra_> but not by the free framebuffer driver we ship by default
<diwic> doko, ok, just wanted to make sure you saw there were two patches. Let's hope it works then :-)
<festhead> ogra_, so no support?
<ogra_> ??
<ogra_> sure, but you need the pvr driver from the TI PPA
<festhead> ok
<ogra_> as ndec stated a while ago already
<festhead> thanks
<ogra_> welcome :=
<ogra_> :)
<ogra_> hmm, the log in the banshee bug looks suspiciously like an ubuntu-one issue
<ogra_> it seems to die in a function called U1RequestChrome
 * ogra_ removes banshee-extension-ubuntuonemusicstore for a test
<ogra_> hmm, sadly no
<GrueMaster> Hmm. No record device according to pulseaudio.  This may take a bit to figure out.
<ogra_> might even be the kernel
<diwic> GrueMaster, does the device show up in "arecord -l"
<GrueMaster> There are a lot of devices that the SOC can handle.  Question is figuring out the right one for alsaucm so that pulseaudio works.
<diwic> right.
<festhead> ogra_, still no succes, i allready had those drivers. i'm using a pico projector and my resolution is only 848x480. no succes with xrandr
<ogra_> how is that attached ? HDMI ?
<festhead> yes
<ogra_> well, try to catch robclark, he knows about graphics drivers and might have more ideas, i'm running out of them now
<festhead> robclark, any ideas? :)
<ogra_> its likely that your projector doesnt provide an EDID table the driver can handle
<festhead> thanks for the help anyway
<robclark> festhead, ogra_, no EDID for pico..
<ogra_> aha !
<robclark> it and LCD panels would only support current resolution
<festhead> no ability to force resolution?
<ogra_> boot with a monitor that has a supported resolution for the pico ... then plug over ?
<festhead> haha! thought of that, but i have no hdmi-monitors. i tried the standard resolution (by plugging nothing in) but that was even smaller
<ogra_> yeah, thats 640x480
<GrueMaster> festhead: Do you have a DVI monitor?  You can use a DVI<>HDMI cable.
<festhead> no only big vga monitors
<GrueMaster> ouch
<ogra_> hmm, oem-config-remove is just running here for whom it intrests ...
<ogra_> on the most recent image
<GrueMaster> robclark: Does the kernel module still accept parameters for video resolution?
<GrueMaster> ogra_: Which image?
<ogra_> desktop panda
<robclark> GrueMaster, yes, although it is different from the omapfb bootargs of old
<ogra_> initramfs-tools is running atm
<robclark> other caveat: for displays that don't support EDID, there is only one valid resolution to choose from
<robclark> ie, you can't set arbitrary resolution on the LCD panels on blaze, for example
<robclark> or pico projector
 * robclark is referring to projector built in on blaze, not one connected over hdmi/dvi..
<robclark> for something connected over hdmi/dvi, it all depends on what the EDID says
<GrueMaster> ok.  Is there a way to fix festhead with a kernel cmdline parameter?  Is it documented somewhere?
<robclark> well, *if* he is using the drm driver, and connecting over hdmi/dvi, and still just gets one choice of resolutions, that probably means that it is all that the display supports
<robclark> no amount of bootargs would change that
<robclark> if he is using older omapfb stuff instead.. then there are some bootargs that would help
<ogra_> GrueMaster, and finished, i'm at lightDM proper
<GrueMaster> ogra_: What image?  What platform?
<ogra_> again pnada desktop latest image
<ogra_> sandisk class4 4G card though ... vers slow (one of the blue ones)
<ogra_> hehe, and the boot partition is automounted
<GrueMaster> Hmm.  Will have to test on other cards.  My 16G Class 6 Micro Center SD fails consistently.
<ogra_> and apport pops in my face
<GrueMaster> Nice.  I just got a segfault probing for recording devices on my panda.
<GrueMaster> kernel oops.
<infinity> ogra_: The boot partition rename thing hasn't landed in current images yet.
<infinity> ogra_: But the fix is in. :P
<ogra_> yep, thats why i laughed
<ogra_> but still no TI icon
<ogra_> grmbl
<infinity> Where's the TI icon meant to be coming from?
<ogra_> jasper
<ogra_> well, its *meant* to be coming from a ti-ppa package but that always slipped
<ogra_> that jasper does it is one of these eternal interim solutions
<ogra_> its there and all, the prob is that it dopesnt show up in the launcher
<ogra_> the prob here is that we need to append to the gsettings value for the launcher favorites
<ogra_> without trashing them
<ogra_> ah, the favorites are defined in /usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml
<ndec|home> ogra_: if it's too much troubles i don't care getting rid of the icon... it would be a little less user friendly, but we can live with that.
<GrueMaster> of course they are. o_O
<ogra_> ndec|home, well, i still have until 23:00
<ogra_> GrueMaster, in natty they were somewhere completely else :)
<ndec|home> i don't want you to feel bad if you don't make it ;-)
<GrueMaster> And in P, they will change yet again.
<ogra_> ndec|home, k, but i'll try my best at least ... its one hack less if i dont make it though
<ndec|home> what is 'they'?
<ogra_> ndec|home, the gnome desktop defaults
<ndec|home> ah ...
<ogra_> in gconf mangling the defaults was easy
<ogra_> gsettings/dconf requires the config files to be compiled after changing them ... thats a bit more tricky
<ogra_> apparently thats an improvement
<ogra_> i havent found out for whom yet, but it surely is for someone
 * ogra_ wonders why favorite entires all need to have the .desktop suffix in the name ... 
<ogra_> its not that there would be any other file format it accepts
<ogra_> sniff ... just adding it doesnt help apparently
 * ogra_ wonders if unity-2d has its own favorites
<GrueMaster> Probably.
<GrueMaster> Add something to the bar, then find/grep for it.
<GrueMaster> (usually much faster than figuring out where, if any, updated documentation may be)
<ogra_> GrueMaster, i want to change the defaults, drag/drop adding it will place it somewhere totally different
<ogra_> (in the config)
<GrueMaster> Will it?
<ogra_> yes
<ogra_> it just dumps the .desktop file in a certain place in your user config
<ogra_> while i need to set a configuration key
<GrueMaster> Should be somewhere in either /etc or /usr/share then (if standards are being followed).
<ogra_> right
<ogra_> in /usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml
<GrueMaster> But that is unity.  Not unity-2d.  Or do they share the same files (like they should).
<ogra_> yes
<ogra_> they use the same backend for the dash
<ogra_> and lanucher
 * ogra_ finds it irritating that gnome-power-manager turns the battery icon red here and shows 2:12 next to it
<GrueMaster> ogra_: On your panda install, did you notice the background behavior during oem-config?
<ogra_> bah, clicking the ti icon does nothing, i guess the gnome-open apt: protocol changed too
<ogra_> GrueMaster, you mean wallpapers ?
<ogra_> yes, its ugly but i doubt we can do much abouot it now
<GrueMaster> Well, the black screen that reveals the wallpaper when you move the mouse.
<ogra_> ARGH !!!!!!!!!!!!!
<ogra_> GrueMaster, yeah, thats an old xfbdev bug, we had it on beagles and babbages too
<ogra_> great, so the TI icon doesnt work because gnome-open doesnt exist anymore
<ogra_> ah, its xdg-open nowadays
<GrueMaster> yea, gnome-open is so last cycle.  :P
<ogra_> its libgnome2 !
<ogra_> well, igot it working if you navigate to /usr/share/applications and click it now
<ogra_> but still not in the launcher
<GrueMaster> sigh.  20110928 daily fails oem-config on another SD card of mine.  yea.
<Neko> oh, btw.. is there any reason when you install an optimized driver for Xorg, it's still loading fbdev in the background?
<GrueMaster> Ah, second run seems to be removing oem-config now.
<Neko> we got some really odd performance problems down to that on the Efika
 * ogra_ points Neko to #ubuntu-x
<Neko> yeah I thought as much....
<ogra_> YAY !
<Neko> happens on Panda too, oddly...
 * ogra_ got it 
<infinity> ogra_: \o/
<ogra_> i see the TI icon in the guest session
<ogra_> seems dconf is really really evil and writes the full defaults as a binary blob into the user dir
<GrueMaster> ogra_: But does it blend?
<ogra_> so later system default changes dont get noticed
<infinity> Given that no one needs that icon except on fresh installs (well, in theory), that seems reasonable. :P
<ogra_> GrueMaster, well, its a bit brownish
<ogra_> infinity, its still a bug bjut seems its a unity one
 * ogra_ thought the new system was that bad, but seems it only applies to the launcher defaults
<GrueMaster> wow, doing a netinstall to an SD takes a loooong time.  Started it at ~11:30.  Still running.  Just asked for task selection.
<GrueMaster> And this is from a local mirror.
<infinity> ogra_: I'm not sure I'd call that a bug.  If it is, it's a bug in pretty much every X application.
<infinity> ogra_: System defaults are applied on first-run and/or user creation, they don't get re-applied.
<ogra_> infinity, gconf worked differently
<festhead> hi! where can i find a free compiler for the dsp (TMS320DMC64X+)  on the omap4430 chip?
<ogra_> infinity, could you take a cross check on commits 172 and 173 in the jasper-initramfs tree ?
<ogra_> s/take/do/
<infinity> ogra_: sed on an XML file, really?  There's no prescribed sane way to do this?
<ogra_> infinity, well, i stole from casper
<ogra_> so i assumed its a blessed way
<ogra_> the xml file is the input i dont think there is a saner wayx
<ogra_> (teh actual config gets generated from it as a binary blob)
 * infinity sees no such code in casper...
<ogra_> http://paste.ubuntu.com/699291/
<ogra_> i could instead put an com.canonical.Unity.gschema.override in place but i still need to pull the key out of the xml file and generate a new value
<ogra_> oh, and .override files are .ini format :P
<ogra_> (for consistency i guess :P )
<infinity> Anyhow, it does the same thing as what you just pastebinned.  So, yay for that?
<infinity> But I still can't find that in the casper source. :P
<ogra_> might be in some edubuntu package that adds to casper
<infinity> Possibly.
<ogra_> its all edubuntu bits and stgraber actualyl gave it to me in -desktop
<infinity> I'm going to assume you've tested that shell on your system in an isolated script?
<infinity> But, if the edubuntu bits work, this should too.
<ogra_> so ok to upload ? (i might have it written differently, but i know the casper code has been tested already)
<infinity> Yeah, I'm all for cargo-culting tested code.
<ogra_> hehe
 * ogra_ rolls the package 
<stgraber> ogra_: it's from edubuntu-live
<ogra_> ah
<infinity> Oh.
<infinity> ogra_: Quoting.
 * ogra_ looks 
<infinity> ogra_: [ -e $FOO ] and [ -e "$FOO" ] behave very differently.
<ogra_> yeah, seeing it
<infinity> (Shouldn't be an issue, since you explicitely set it to a string, but I'm paranoid.
<ogra_> fixed
<infinity> )
<ogra_> and you shoudl be
<ogra_> especially on my code past 8pm local time
<ogra_> :)
<stgraber> ogra_: I actually learned about the override stuff later on but haven't had a chance to test them yet and IIRC you still need to update the binary db, so it's just cleaner (but I usually don't care much about cleanliness in a casper hack as long as it works ;))
<ogra_> yeah
<ogra_> i dont actually think the .override file gains you much
<infinity> Well, the obvious problem with the hack is that it fails to work if the entry that you're anchoring your regex on goes away. :P
<ogra_> yeah
<ogra_> thats easier in casper indeed
<stgraber> right, but the override would need to hardcode the whole list, not much better :)
<ogra_> since yuo can tie to ubiquity
<ogra_> exactly
<ogra_> thats waht i didn in gconf though
<stgraber> it's fairly safe to assume that something using casper will have ubiquity installed (at least it's for Edubuntu) :)
<ogra_> right, we dont use casper
<ogra_> and dont have an ubiquity item in the launcher
<infinity> ogra_: we do at the time that jasper-setup runs. :)
<ogra_> i would actuallyx have preferred to pull the whole value out of the file, but grepping in xml is just moot
<ogra_> infinity, we do what ? use casper or have an ubiquity item ?
<infinity> ogra_: The latter.
<ogra_> i think the latter is put in place by casper
<infinity> ogra_: The launcher only goes away after oem-config runs.
<ogra_> oh, really ?
<ndec|home> festhead: http://linux-c6x.org/wiki/index.php/Downloading/Installing_Software
 * ogra_ has never checked 
<ogra_> i always thought casper handles it
<infinity> ogra_: It's why we've had an open bug until 3 days ago about an "install icon on the launcher".
<ndec|home> festhead: http://omappedia.org/wiki/Syslink_Project#Ducati.2FTesla_IPC_Source_Code
<ogra_> oh, indeed
<ogra_> heh, i think i even commented on it
<festhead> ndec: thanks!
<ndec|home> jussi: saw that you got the answer on #pandaboard ;-)
<infinity> ogra_: Anyhow, whatever.  If that works, it's good enough for me for now.  It's an ugly hack regardless.
<ogra_> yep
<ogra_> well, all that PPA stuff should be in a package proper
<ogra_> we should do that when implementing the "jasper needs to die in fire" spec
<ogra_> aaand ... uploaded
<ndec|home> GrueMaster: ogra_: infinity: you knew that alsa-lib changes was done in linaro ubuntu overlay PPA? https://launchpad.net/~linaro-maintainers/+archive/overlay/+packages
<ogra_> ndec|home, no :(
<ndec|home> rsalveti: why would such a change be done in the overlay PPA before it gets done in ubuntu?
<ogra_> why wasnt it just fixed in the archive
<ndec|home> ;-)
<ogra_> ndec|home, i suspect because they use natty
<ndec|home> true, they use alsa-lib from oneiric..
<ogra_> though we have a policy in ubuntu that fixes happening in an SRU (which such a PPA effectively is) have to happen in the dev release as well
<ogra_> we should probably discuss how to fix that for teh future at UDS
<ndec|home> well, at least we have it in the archive too ;-)
<ogra_> now, yes
<ogra_> and with wasting at least 1h of three devs for discussing it
<ogra_> i think we can do better ;)
<ogra_> 22min to freeze ...
<ogra_> i think i'll call it a feierabend :)
<ndec|home> your first release with audio?
<ogra_> ndec|home, so we will need an oneiric metapackage in the ppa ... do you want to do that ?
<ogra_> yeah, that too :)
<ndec|home> i will do that.
<ndec|home> we have the gfx packages already in the ppa.
<ogra_> thx, essentially i think its just copying the existing one and adjusting the deps
<ogra_> for whats there atm
<ndec|home> we will upload the meta pkg
<ogra_> great, thx
<ogra_> icon is back too :)
<ndec|home> ;-)
<rsalveti> ndec|home: ogra_: first, we're now using the same kernel
<rsalveti> second, I said already that I had the changes needed for the tilt before the tilt was merged at ubuntu
<rsalveti> third, I fixed this *yesterday* :-)
<rsalveti> for the release, then before pushing to ubuntu I first need to check and validate with the current ubuntu kernel
<rsalveti> and due lack of time, this wasn't done already
<rsalveti> and ubuntu is going to final freeze
<rsalveti> I don't want to push changes that might fix the issues :-)
<rsalveti> only want to push things that I sure it'd be a solution for the problem
<rsalveti> and the latest ucm configs were all posted at the no sound support for omap4 bug, just that nobody saw it
<rsalveti> https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/746023/comments/50
<ubot2> Ubuntu bug 746023 in alsa-utils "No sound on omap4" [High,In progress]
<rsalveti> when I commented about the issue :-)
<ndec|home> rsalveti: are the panda config files different from the SDP4430 ones?
<ndec|home> in your pkg
<rsalveti> ndec|home: currently, no, but we're using the configs provided by the multimedia wg
<rsalveti> I guess it's not the same one ubuntu is using
<ndec|home> i will check tomorrow. sound is working with our config, at least on headset.
<rsalveti> only issue is that hdmi out doesn't seems to be working anymore
<rsalveti> just jack
<rsalveti> but didn't have time to investigate the issue yet
<dash> just got an mx53 board, it's pretty sweet. i'm installing natty on it
<dash> anybody know about getting the nfs kernel server going? do the natty kernel images not support that
<GrueMaster> dash: Instead of trying to get natty on it (which we don't support on that platform), why not try oneiric?  The latest daily image works, although you may need to create a swap file.
<GrueMaster> The natty images are TI only.
<dash> GrueMaster: ach! oneiric sounds fine to me, but the wiki said "works like a charm" for mx53 and natty :)
<dash> i've already got a swapfile anyway, no big deal :)
<GrueMaster> Erm, which wiki?
<infinity> GrueMaster: They ship with natty on an SD.
<infinity> (And a freescale kernel)
<GrueMaster> Ah.  Yea, they are making their own image.  Ours has the latest kernel and other Ubuntu bits.
<dash> The board came with lucid.
<dash> GrueMaster: I was looking at this: https://wiki.ubuntu.com/ARM/DeviceSupport
<dash> It doesn't say "natty", I imagined that part, I guess. :)
<GrueMaster> dash: Type "cat /etc/lsb-release".
<dash> GrueMaster: well it says natty /now/
<dash> 'cause I upgraded
<dash> but sources.list was all lucid
<GrueMaster> Yea, that's what I thought.  It shipped with Lucid, not Natty.  At any rate, oneiric has an image for that platform now.
<dash> awesome.
<brandini> evening dudes
<sniperjo_> in /boot/tools there is a file called update_boot_files.sh, how do i run it ? nothing happens when i chmod +x it
<GrueMaster> /boot/tools?  Not one of our directories that I am aware of.
<sniperjo_> I'm praying its the answer to all my problems, i want to update boot.scr
<brandini> I just did a dist-upgrade to the daily from the 28th
#ubuntu-arm 2011-09-30
<sniperjo_> if i connected to my board with serial, it would say last login from â¦. would it sound weird to have ttyS2 instead of tty02 ?
<ndec1> ogra_: infinity: you know that the alsa-lib updates from last night is wrong?
<ndec1> grep SDP4430 /usr/share/alsa/ucm/Panda/*
<ndec1> is wrong...
<ogra_> aww, thats alsa-lib instead of alsa, right ?
<ogra_> hmm, no
<ogra_> whats wrong about it =
<ogra_> ?
<ndec1> no. the ucm files are in share/alsa/ucm
<ndec1> do you have audio working?
<ogra_> the .conf is in the subdir here
 * ogra_ isnt near a panda and actually on his way out atm
<ogra_> i'll test when i come back
<ogra_> (some RL stuff)
<ndec1> if you run alsaucm it use the UCM config to config the driver, and the config params are taken in the script. in the Panda scripts we have thinkgs like hw:SDP4430 which will fail on Panda...
<ndec1> GrueMaster: ^^
<ogra_> right
<ogra_> so that might need a fix then
<ogra_> infinity, ^^^
<infinity> It was fixed.
 * ogra_ -> really out now ... will be back for the call
<ndec1> infinity: nope. you didn't change the params in the config file. you still have references to hw:SDP4430 *inside* the files.
<ndec1> on my panda:
<ndec1> alsaucm -c Panda set _verb HiFi
<ndec1> Im setting defaults
<ndec1> ALSA lib main.c:260:(execute_sequence) unable to open ctl device 'hw:SDP4430'
<ndec1> ALSA lib main.c:1287:(set_verb_user) error: failed to initialize new use case: HiFi
<infinity> Oh, feh.  I forgot the sed on the version I uploaded.
<ndec1> after the upgrade
<infinity> Balls.
<infinity> It was right in the local test version. :/
<infinity> ndec1: Fixed.
<ndec1> great.
<infinity> ndec1: Thanks for the catch.  Annoyance of testing on one machine and uploading on another. :/
<ndec1> while(1) apt-get update && apt-get upgrade ;-)
<janimo> infinity, are idle arm builders assigned build jobs randomly or is there a prioritization?
<infinity> janimo: It's either alphabetical or based on a serial in the table (ie: it's just a table lookup), but you could talk to wgrant about seeing if they can be reordered. ;)
<janimo> infinity, would make sense to reoder and put pandas first no?
<infinity> janimo: I suppose, except that armel isn't keeping those anyway.
<wgrant> It's pretty much random and difficult to change.
<infinity> wgrant: Shouldn't be random, surely.  I'm sure it's deterministic.
<janimo> wgrant, so not even alphabetical as infinity said?
<wgrant> infinity: Deterministic, but not predictable.
<infinity> wgrant: I'm assuming based on the order they get spit out of the table.
<wgrant> infinity: Not any more.
<infinity> Oh.
<infinity> Because SQL is hard, and we had to do it even worse? :)
<wgrant> Each builder has its own state machine in the Twisted daemon.
<infinity> Oh, right.
<wgrant> It's entirely asynchronous.
<janimo> the name is fitting
<infinity> I forgot about the parallel rewrit.
<infinity> e
<wgrant> Once a builder is done, we schedule the next scan for 15s from whenever it finished.
<wgrant> And dispatching is done on a per-builder basis.
<wgrant> So whenever a builder is not building anything, the next scan will query the DB to see if there are any jobs.
<wgrant> We could possibly rework it to queue a bit differently, but at present no statement can be made about the ordering.
<infinity> Yeah, like I said, I forgot entirely about that rewrite.
<infinity> No point trying to weight them.
<wgrant> Speaking of armhf... when's it going to happen?
<infinity> wgrant: Well, we may have missed our cutoff for getting a gcc upload in. :/
<infinity> wgrant: So, it might just have to open with P.
<wgrant> Yeah.
<infinity> Not happy about all the delays, but whatever.  Life goes on.
<infinity> We'll just have to get an army of Pandas to make up for it.
<janimo> or imx53s as they are easier to get
<wgrant> Maybe we'll have A15s of some variety eventually...
<janimo> infinity: bzr commit, git log -p|less. you are not alone
<ogra_> janimo, the panda cluster took a year to happen from when i made the first proposal to today
<ogra_> janimo, better bet for mx56 or so :)
<ogra_> or mx58 or however freescale will call the overnext generation
<janimo> ogra_, a difference is pandas were scarce, whereas imx53 seems to be in good supply
<ogra_> janimo, still you need to desing the whole crap
<janimo> and the needs more pressing now and also the communication better
<janimo> davidm, said they'd fit in the same case he designed
<brandini> imx53 eh?
<Neko> ogra, i.MX615 probably is the next big chip
<Neko> with a D or a Q at the end for how many cores it has
<ppisati> actually if i disable SUSPEND*, panda doesn't hang anymore
<ppisati> i really don't understand how they reproduced it without SUSPEND support
<ppisati> doh
<ogra_> yeah, me neither
<ogra_> but they also use the pvr driver
<ppisati> but that is still triggered only from suspend
<sebjan> ppisati: you disabled SUSPEND support in the kernel, right?
<ppisati> sebjan: as a test?
<ppisati> sebjan: yes, and it doesn' hang anymore
<sebjan> ok
<ppisati> the kernel in the archive has
<ppisati> (wait)
<ppisati> http://paste.ubuntu.com/699814/
<ppisati> this is what i reverted
<ppisati> this way, no more hangs
<ogra_> well, as i said in the call, its mostly a gnome-power-manager bug ....
<ogra_> which is being worked on
<ppisati> so, we keep it on?
<ogra_> well, it doesnt work on the kernel side either ... we might want to switch it off :)
<ppisati> asd :)
<ogra_> that suspend doesnt work and that g-p-m triggers suspend are surely two separate bugs
<ppisati> well, actually i think the only bug is kernel side
<ppisati> g-p-m is a bit too aggressive IMO
<ppisati> to suspend the thing after 30mins
<ogra_> well, the system forcefully goes to suspend after 30min idle time
<ppisati> yep
<ogra_> thats the g-p-m bug
<ppisati> yep
<ppisati> anyway
<ppisati> if we can't work it out, i switch it off
<ppisati> ok?
<ogra_> yep
<ogra_> doesnt do any good to have it on :)
<ogra_> if it just locks the system at least
<ppisati> righty right my friend :)
<sebjan> yes, it's safer/easier to deactivate it for now
<ppisati> sebjan: does it happen with
<ppisati> sebjan: git://git.linaro.org/ubuntu/linux-linaro-oneiric.git too?
<sebjan> ppisati: I don't know. Not sure if this tree has the TI patches
<sebjan> ppisati: I use the tilt-linux-linaro-3.0 branch from Andy's tree
<ppisati> sebjan: ok, and it does exhibit the problem even with no SUSPEND, right?
<sebjan> ppisati: well, we can see a similar problem with no suspend but are unsure of its origin. It could be related to the sgx driver activation. That will be interesting to test Ubuntu kernel + sgx
<sebjan> (in this case we don't have any suspend traces in the console)
<ppisati> sebjan: and how do you reproduce it?
<ppisati> sebjan: just leave the board idle?
<sebjan> ppisati: well, just wait some time :)
<brandini> anyone build mongodb lately?
<brandini> the 2.0 release builds
<ppisati> sebjan: half an hour is enought?
<sebjan> ppisati: not sure. I know it happens quickly sometimes
<ndec1> ogra_: i remember there was an installer bug yesterday. what was this problem?
<ogra_> bug 806751
<prpplague> ndec1: you have a ti branch you are using to test 4460 support?
<ubot2> Launchpad bug 806751 in debian-installer "Boot partition on SD is too small on omap/omap4" [Medium,New] https://launchpad.net/bugs/806751
<ogra_> bug 820621
<ubot2> Launchpad bug 820621 in flash-kernel "netinstall fails to make omap system bootable during install" [High,Fix released] https://launchpad.net/bugs/820621
<ogra_> bug 709245
<ubot2> Launchpad bug 709245 in linux-ti-omap4 "ARM SMP scheduler performance bug" [High,Fix committed] https://launchpad.net/bugs/709245
<ogra_> bug 779410
<ubot2> Launchpad bug 779410 in flash-kernel "package initramfs-tools 0.98.8ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Fix released] https://launchpad.net/bugs/779410
<ndec1> all fix are in the archives?
<ndec1> since when?
<ogra_> ndec1, sorry, that wasnt for you, i'm preparing the release report for #ubuntu-meeting
<ndec1> ah!
<ndec1> ogra_: we are getting 'installer crashed' with one of our recent image. could we be missing a pkg?
<ndec1> that you've fixed?
<ogra_> hmm, we fixed plenty things
<ndec1> ogra_: does the very latest image work fine ? e.g. for the installer?
<ogra_> for me the last image worked, yeah
<ogra_> i used it yesterday to hunt down the icon bug
<GrueMaster> ndec1: There are still issues during oem-config that I see, but they are very timing specific.  I can reliably reproduce them here on some SD cards, but not others.
<GrueMaster> This is the 20110928 image.
<rsalveti> prpplague: there's one from the ti landing team
<rsalveti> prpplague: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-linux-linaro-3.0
<rsalveti> I know this branch works fine at 4460
<prpplague> rsalveti: yea ndec1 pointed me to that one
<rsalveti> there's also the tracking branch, based on 3.1
<rsalveti> but not working properly I believe
<rsalveti> missing some hwmod changes
<ndec1> correct
<ndec1> prpplague: what was the question?
<prpplague> ndec1: just need a build for some 4460 testing
<ndec1> prpplague: funny you ask... because if I needed one i would generally ask you ;-)
<prpplague> ndec1: hehe, well, i;'ve been testing the head of all the TI trees and everyone has something wrong with them
<ndec1> prpplague: there isn't just 1 tree?
<prpplague> ndec1: no
<ndec1> ;-)
<rsalveti> haha :-)
<ppisati> sebjan: i left the board idle for a while but no hang
<ppisati> sebjan: titl-linux-linaro + ubuntu userspace
<ppisati> dist-upgrade an hour ago or so
<ppisati> sebjan: ok, if i force the suspend it hangs
<ppisati> as expected
<prpplague> ndec1: core 4460 support so far looks good on that one you referenced
<kyleN> I am going to try my cruzer key (not the kingston)
<infinity> Hey look, the slideshow works.
<infinity> That's much less ugly.
<prpplague> GrueMaster / ogra_ any of you guys know if userspace spi dev is enabled in the panda supported kernels?
<prpplague> (for ubuntu releases that is )
#ubuntu-arm 2011-10-01
<dash> hi. anybody running oneiric on an mx53? i'm trying to upgrade to the oneiric kernel and not finding an initrd for it
<dash> what am I missing to make this work? :)
<twb> lilstevie: ping.
<twb> lilstevie: you said I could test u-boot by loading it into memory, rather than writing it to the emmc.  I couldn't work out how to do that, though.
<twb> I was trying: ./nvflash --bct BCT.img --setbct --configfile flash.cfg --bl EBT.img --go --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98
<twb> Where EBT.img is u-boot.bin
<lilstevie> twb: that is it
<twb> Hum
<lilstevie> issuing --sync will also do it, cause u-boot doesn't understand --sync :p
<twb> http://paste.debian.net/133438/ is what it said
<twb> Also I didn't get anything on screen, but that might just be because my u-boot image is still screwed
<twb> btw, one of the qemu guys gave me a patch that fixed segfaulting sometimes when chrooting into a armhf rootfs -- it was due to it not zeroing memory before handing it out or something
<twb> *due to it = due to qemu
<lilstevie> that will be because your u-boot is screwed
<lilstevie> the nvflash output is expected
<lilstevie> but not getting output is cause something is wrong
<twb> ok, thanks
<twb> I used gcc 4.4 and everything :-/
<dash> good morning
<dash> anybody know why my oneiric kernel package doesn't have an initrd yet flash-kernel expects one? :)
<twb> initramfs-tools makes tramdisks
<dash> yeah i'm running it manually now
<twb> initramfs -u -k all
<twb> Er, update-initramfs -u -k all
<dash> ah, i did -c
<twb> It's supposd to trigger via /etc/kernel/post-inst.d
<twb> I guess if you did debootstrap --foreign or something to unpack your kernel deb, that might not trigger
<dash> hmm nope, used aptitude
<twb> Shrug
<dash> yeah.
<dash> oh well
<dash> linux-image-linaro-lt-mx5 is the right thing if i'm installing on an i.MX53 quickstart board, right?
<twb> NFI
<dash> ok :)
<twb> As my schoolteacher used to say: "look, I just work here"
<dash> yeah my boss never thinks it's funny when I say that to him
<brandini> hrmmm, I wonder when mongodb will build and work properly
#ubuntu-arm 2011-10-02
<twb> lilstevie: I dunno what's going on, man, I even rebuilt u-boot.bin using gcc-4.4 from a Debian armel (i.e. no hf) chroot
<twb> I still don't get anything onscreen when I upload it to the TF
<twb> lilstevie: can I get a copy of the bootloader you've got, that's working, so I can try uploading it to mine and at least see if that works?  That will show 100% that I'm compiling it wrong, and not simply uploading it wrong.
<twb> So fun story, because u-boot isn't working, it goes into APX mode, and holding the power button just reboots, not halts.
<twb> Which is why the last two weeks, when I've pulled it out to try reflashing it, it has been completely drained of power
<twb> (bleh)
<lilstevie> lol
<lilstevie> twb: charge it for a few hours then
<armin76> haha
<twb> Yeah, that's what I've been doing, but it's not healthy for the battery to stay fully discharged, or to stay on power 24x7, so I reinstalled your ubuntu image just so I can actually turn it off :P
<twb> 17:54 <twb> lilstevie: can I get a copy of the bootloader you've got, that's working, so I can try uploading it to mine and at least see if that works?  That will show 100% that I'm compiling it wrong, and not simply uploading it wrong.
<lilstevie> ok, gimme a sec
<lilstevie> twb: I lost my active u-boot in my HDD meltdown
<twb> <sad face>
<Spider-Pork> Hi, i would to install ubuntu on my gumstix over fire (with Omap3530). Has anyone experimented it? What version is recommended? Thank you
<Spider-Pork> I'm not interested on X11 support, i need only shell and, of course, the ubuntu system (that i love)
<TurboFreak> Hi!
<TurboFreak> I've got a small problem with ubuntu on my Beagleboard-xm: http://ubuntuforums.org/showthread.php?t=1845646
<TurboFreak> I hope there is someone who can help me.
<TurboFreak> I can't get my Keyboard and Mouse work with Ubuntu on the Beagleboard.
#ubuntu-arm 2012-09-24
<seismic__> hey, are ubuntu-ports armhf binaries compiled for armv7+VFP?
<lilstevie> seismic__, that is what hardfloat is :p
<seismic__> lilstevie: cool, just to be sure ;)
<lilstevie> :)
<lilstevie> seismic__, armhf is armv7 using vfp for floating points, the only major thing armhf doesn't cover is neon
<lilstevie> and that is due to some armv7 cores out there not supporting neon
<seismic__> lilstevie: ok, i see
<ogra_> rsalveti, do you know if https://launchpad.net/ubuntu/quantal/+source/xbmc/2:11.0~git20120510.82388d5-1ubuntu2 could also build for arm ? or is it missing patches ... ?
<ogra_> rsalveti, oh, ignore me, i'm blind
<ogra_> (somehow my brain was looking for armel in the archiers list)
<ogra_> *arches
<int_ua> I'm constantly getting a couple of "Buffer I/O error on device loop1, logical block 494320" while mounting/working with 12.04 OMAP preinstalled image. Can anyone suggest what's the problem?
<ogra_> int_ua, well, what did you loop mount ?
<int_ua> sudo mount -o "loop,offset=75497472" -t auto ubuntu-12.04-preinstalled-desktop-armhf+omap.img /mn
<int_ua> ogra_: ^
<ogra_> ohm, i thought you meant when running it :)
<int_ua> ogra_: doesn't it mean that the image FS is broken?
<ogra_> might be, it doesnt stay like that since on first boot the SD gets re-partitioned and the FS gets adjusted to the SD
<ogra_> i havent loop mounted an image in quite a while i must admit
<int_ua> Where should I report it?
<ogra_> (and preinstalled is dead from 12.10 on)
<ogra_> you could report it against debian-cd i guess but dont expect it to be fixed, loop mounting the images is a corner case and arm wasnt even rebuilt for 12.04.1
<ogra_> and as said, this image type is dead
<int_ua> orga_: What's the proposed replacement if it's dead? Ubuntu Core?
<ogra_> well, for omap there is still ubuntu-server
<ogra_> beyond trhat all images are now simple live/alternate images like on x86
<ogra_> the preinstalled hackery is gone
<int_ua> ok, thanks
<ogra_> ubuntu core isnt an image
<ogra_> it is a base for building images
<ogra_> (or a cheap way of getting a chroot)
<int_ua> The same thing for Kubuntu, just different logical blocks
<Heradon> good morning
<Heradon> I have a question and that is responsible for the uboot you can load a image from MMC or does boot.axf?
<hrw> boot.axf?
<LetoThe2nd> sounds like armcc. bah.
<Heradon> on my gooseberry (android) is an nanda/boot.axf i think this is the firmware
<Heradon> i have build sucessfully a new u-boot.bin but boot from mmc is not possible
<Heradon> but the android boots without a problem ^^
<ogra_> damned ... i cant get the console up with more recent kernels on the zatab
 * ogra_ doesnt get that
<ogra_> sigh
<ogra_> yay, at least i see 1G now
<ogra_> (well, 900+M )
<ogra_> oha, we used the totally wrong kernel branch for allwinner it seems
<ogra_> there is apparently a branch based on 3.0.42
 * ogra_ clones 
<hrw> ogra_: allwinner? does it hurts badly?
<ogra_> well, so so
<ogra_> i have a kernel that has a working console now and that allocates the full 1G if i use mem=
<ogra_> no success with the mmc ot touchscreen drivers yet
<ogra_> *or
 * xnox ponders if the way I wrote lvm support in ubiquity increased memory usage
<xnox> and if it did, whether it was significant....
<ogra_> who uses lvm anyway :)
 * xnox does
<xnox> :P
<xnox> who uses arm anyway ;)
<ogra_> xnox, everyone using a mobilephone ;)
<sauerbraten> using the precise ubuntu core rootfs on a pandaboard I can't use my keyboard. at no point is there any power (i.e. the lock leds never light up). known bug / not a bug?
<hrw> ogra_: there are !arm mobilephones ;)
<sauerbraten> pandaboard A2 btw
<ogra_> hrw, rarely :)
 * hrw -> off
<ogra_> sauerbraten, kernel issue i would say, and no, not known (works fine here)
<ogra_> sauerbraten, do you have a proper power supply attached (3A or bigger)
<sauerbraten> mhm... I only untared the rootfs to the second partition and put MLO, u-boot.bin and uImage onto the boot partition from http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/
<sauerbraten> it worked with arch linux for arm, for example, so I guess. let me check though
<sauerbraten> 2.5A
<ogra_> no usb disk ?
<sauerbraten> nothing but the keyboard
<ogra_> then 2.5A should eb fine
<ogra_> *be
<ogra_> where did you get the required initrd ?
<sauerbraten> I didn't get one. do I need one? ooops
<ogra_> (or how did you produce it)
<ogra_> ah, well, i think the HID stuff is modules :)
<sauerbraten> I followed http://www.omappedia.com/wiki/OMAP_Ubuntu_Core and there was no mention of it
<ogra_> do you have an ubuntu PC around ?
<sauerbraten> I'm on xubuntu right now, installing xubuntu-desktop to the SD card, to see if xorg gets my keyboard
<ogra_> nah, wait
<ogra_> first install linux-omap4
<ogra_> so you get the modules
<sauerbraten> mhm, you're too late, but I'll do that when xubuntu finishes :)
<ogra_> any reason why you started off so compicated ?
<ogra_> nothing will be in sync with the defaults of an ubuntu system that way
<sauerbraten> I read https://wiki.ubuntu.com/Core/InstallationExample where it says to install a kernel and the dependencies, but I couldn't find linux-image for arm so I left that out
<sauerbraten> so it's named linux-omap4?
<ogra_> yes
<ogra_> why do you actually use core ... its not really designed for this
<sauerbraten> I used ubuntu for arm but it was really slow
<ogra_> ??
<sauerbraten> what?
<sauerbraten> I mean the UI
<ogra_> ubuntu for arm ... what do you mean
<sauerbraten> the normal ubuntu build for omap4
<ogra_> well, still core is to build images on top of it
<sauerbraten> https://wiki.ubuntu.com/ARM/OMAP
<ogra_> all the required installer bits arent there
<ogra_> and core is for use as a chroot
<ogra_> you shouldnt try to roll a normel system based on it if you dont exactly knwo which bits and pieces need to be touched
<ogra_> for xubuntu desktop installs just use the server image
<ogra_> it offers you all installable tasks, ubuntu-dekstop or xubuntu-desktop are among them
<sauerbraten> sounds reasonable. well I'll see what I get now and if it fails again I'll try server
<ogra_> and you end up with a properly set up system that doesnt fall over all the time on package upgrades
<sauerbraten> core does?
<ogra_> it will, i,.e. the kernel relies on a properly configured bootloader setup
<sauerbraten> ogra_: will the server image offer a login prompt on hdmi or only serial?
<ogra_> it defaults to run the installer on serial, once installed it will show ttys on all consoles (so on hdmi too)
<sauerbraten> do I have to interact with the installer?
<ogra_> yes
<ogra_> you can rebuild the boot.scr on the first SD partition and drop the console= arg as well as the debian-installer/framebiffer option
<ogra_> that should give you the installer on HDMI by default
<ogra_> (in 12.10 we actually ship a second bootloader config that you can just cp in place if needed)
<ogra_> but 12.10 expects to install to a USB target device by default
<sauerbraten> ogra_: mhm that's bad, I don't have my serial cable with me atm :/ I booted it anyway and the screen got activated, I don't have any prompt though. sure there is an installer on there? it's already 630MB and it's named preinstalled, so...
<GrueMaster> sauerbraten: The installer is oem-config.  It only prompts for localization (username/password, language, timezone, etc).  It is not the full installer.
<sauerbraten> GrueMaster: ok, I had to let go though. I'm now using a minimal biuld from http://rcn-ee.net/deb/rootfs/precise/ which does it's job quite good until now
<GrueMaster> Ok.  I can also help with the preinstalled server image if you want.  The rcn-ee images are a bit customized, and asside from the apps, you won't get much help here.
<sauerbraten> GrueMaster: well I would have to have my serial cable which is about 150km away from where I am :) the repos should be the same as for the original ubuntu though, right? so I will eventually be able to get the graphics to work?
<sauerbraten> I was actually running ubuntu server before I think, but couldn't get X to work properly. I had a nifty little autoupdate config though which I plan on using again
<GrueMaster> sauerbraten: I can help you get around the serial console issue.  It is a simple edit of the boot.scr file.
<sauerbraten> GrueMaster: oooh! well, it's kind of too late now. wanna tell me anyway so I can save a boot.script file in case I switch back to server?
<GrueMaster> Are you using a Linux PC or a Windows system?  You will need to edit the boot.scr on the 1st partition.
<GrueMaster> Give me a second.  looking up the alternate names for boot.scr.  There is a way to edit it and save it as plain text without the u-boot crc header.
<GrueMaster> I actually had this documented on the ubuntu wiki at one point.  Now it is all gone.  sigh.
<GrueMaster> Ok, figured it out.  Edit the boot.scr, remove the binary crap at the beginning, and replace the bootargs with "bootargs=vram=40M mem=456M@0x80000000 mem=512M@0xA0000000 root=/dev/mmcblk0p2 fixrtc quiet splash"
<GrueMaster> And that should work.
<GrueMaster> Save the file as preEnv.txt (delete boot.scr).
<sauerbraten> ok, wrote that down. thanks GrueMaster
<GrueMaster> No problem.  I just wish it had stayed on the wiki.
<sauerbraten> so, after "apt-get install linux-omap4" rendered the system unusable again (no login prompt, no X, though that worked before) I'm now actually gonna use your method, GrueMaster :)
<GrueMaster> Ok.  Let me know how it goes.
<sauerbraten> can you tell me what the bootargs mean? I've used so many different boot.src's now, would be good to know what I'm actually putting in there
<GrueMaster> These are the parameters that uboot passes to the kernel.  They are the kernel boot arguments.
<GrueMaster> Just a different syntax than, say, grub or lilo.
<sauerbraten> but for example  mem=456M@0x80000000 mem=512M@0xA0000000 look like it tells the kernel where to allocate memory or something? why twice?
<sauerbraten> also fixrtc?
<GrueMaster> The mem= lines map memory holes in system memory.  These holes are used for the video decoder.  If you aren't running the omap4 powervr drivers (i.e. stock FB) then you don't need these lines.
<GrueMaster> The fixrtc runs a script that essentially sets the time to the last filesystem write time.
<GrueMaster> Since there is no battery backed RTC in the system.
<GrueMaster> Quiet tells the kernel to quit yapping, and splash will run Plymouth splash screen.
<GrueMaster> Not sure on the vram, but it is omap specific.
<GrueMaster> I think it is for Video Ram.
<GrueMaster> to allocate shared memory as video memory.
<sauerbraten> ok, I will hopefully use the powervr driver :) when you said "remove that binary crap", you meant I can delete the whole file? cause there's nothing in there besides weird bytes
<GrueMaster> It should have had other stuff as well (like the bootargs).
<sauerbraten> doesn't, not in a standard text editor at least
<GrueMaster> What are you editing with?
<sauerbraten> leafpad
<sauerbraten> now checking with cat
<sauerbraten> ok cat shows more
<GrueMaster> Hmm.  Never used that one.
<sauerbraten> I'll try nano
<sauerbraten> yes that works
<GrueMaster> The first 72 bytes are the CRC.
<sauerbraten> this is what's in there besides the CRC bytes http://pastie.org/4793694
<sauerbraten> looks good? now edit the bootargs how you said?
<sauerbraten> actually, this is the whole bootargs line: bootargs vram=40M mem=456M@0x80000000 mem=512M@0xA0000000   root=/dev/mmcblk0p2 fixrtc quiet splash debian-installer/framebuffer=false console=ttyO2,115200n8
<GrueMaster> yes, only just edit the way it looks in the boot.scr (i.e. remove the console= and the debian-installer stuff).
<sauerbraten> ok
<GrueMaster> Yea, so just remove everything after the splash.
<sauerbraten> and the CRC, cause that will be wrong now?
<GrueMaster> Right.
<GrueMaster> Are you on a linux system while editing?
<sauerbraten> yep
<sauerbraten> so, save that as boot.scr or preEnv.txt now?
<GrueMaster> Then you can re-add the crc with mkimage.
<GrueMaster> Save it as boot.script.
<sauerbraten> done
<sauerbraten> now mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "ubuntu server boot script" -d boot.script boot.scr ?
<GrueMaster> then type "mkimage -A arm -O linux -T script -C none -n boot.scr boot.script"
<GrueMaster> Or what you said.
<sauerbraten> yours gave me segfault o.O
<GrueMaster> (I had -n and -d confused).
<sauerbraten> oh ok
<sauerbraten> well, let's try this!
<GrueMaster> I haven't done this since April.
<GrueMaster> Now that you have boot.scr, copy it back to the first partition of the SD and boot in a panda.
<sauerbraten> I always had it on the first partition, was too lazy to even copy it away from there :)
<GrueMaster> That works too.
<sauerbraten> mhm, nothing happening yet, only both LEDs on
<GrueMaster> I used to do this (and many other edits) on a more than daily basis, so I wrote a script.
<GrueMaster> Hmmm.
<GrueMaster> It may be doing the first stage filesystem expansion.  Give it about 5 minutes.
<GrueMaster> The preinstalled images will boot once to expand the rootfs to fill the SD, then reboot into oem-config.
<GrueMaster> And that stage is only visible without quiet & splash in the bootargs.
<GrueMaster> But iirc, one LED should shut off as soon as it loads the kernel.
<sauerbraten> yeah I remember that. we'll see. I also think I remember the SD LED to blink once or twice while it booted ./
<GrueMaster> How did you write the image to the SD?
<sauerbraten> dd and bs=4M
<sauerbraten> it said 1M, but hey
<GrueMaster> ok
<sauerbraten> plus sudo sync, so that shoul have worked
<GrueMaster> Is this a precise image?  img.gz?
<sauerbraten> yes. but wait, I just realized I left the empty preEnv.txt on there
<sauerbraten> maybe the bootloader is confused
<GrueMaster> could be.
<GrueMaster> I need to step out for ~15 minutes.  biab.
<sauerbraten> mhm, I checked my boot.scr and boot.script again and it seems something got messed up (or I did) well, the boot.scr didn't contain anything but the CRC (probably from getting an empty preEnv.txt the first time?) and boot.script was completely erased. I'll copy the original boot.scr now and edit it again, this time making sure to not mess up
<sauerbraten> works now, I even see the resizing splash on HDMI
<GrueMaster> Cool.
<GrueMaster> Should be fairly straight-forward from here.
#ubuntu-arm 2012-09-25
<rsalveti> ogra_: since the latest flash-kernel update was published, the first sd card partition is erased (mkdosfs) during the installer, and the the boot loader files are gone
<rsalveti> causing the image to not boot after the reboot
<rsalveti> don't know yet if plars created a bug for it already
<ogra_> rsalveti, fixed, thanks for pointing it out !
<ogra_> plars, intresting that your file list in bug 1055938 contains all the .bak files ... the partition got accidentially reformatted instead of renamed, theoretically there should be no files to backup ...
<ubot2> Launchpad bug 1055938 in flash-kernel "uboot and mlo not in boot partition after install" [High,Confirmed] https://launchpad.net/bugs/1055938
 * ogra_ wonders how broken the flash-kernel logic to make backup files is here 
<janimo> ogra_, marvin24 does the newest l4t look good in your tests? I have yet to try it out
<ogra_> janimo, still waiting for your kernel
<janimo> in precise?
<janimo> ogra_, but did not test with locally built images?
<ogra_> i have the tarball for r16 ABI 13 here but wait for the kernel to be tested and uploaded
<ogra_> thats for quantal
<janimo> ogra_, ah great
<ogra_> preceise can come once we have the world working in quantal ;)
<janimo> well you could upload the package even so, does it regress if there's no abi13 yet anyway?
<ogra_> janimo, marvin24 has thrown a test kernel around the last days
<janimo> I agree with precise needing the backport only
<ogra_> there is an abi 13 since the weekend
<ogra_> but i need the kernel too :)
<janimo> ogra_, ok will check it out. I was on holiday for the past week and yesterday so missed that
<ogra_> yeah, no hurry as long as we get it in before final freeze :)
<ogra_> i have no time for the driver this week either :) but the weekend is reserved for it
<ogra_> (and we are in beta freeze anyway this week)
<janimo> first hit for l4t is still the older page with the backup info from during when their site had problems
<janimo> ogra_, are the quantal daily installers working for ac100? I still have precise on it
<janimo> ogra_, and the note says disable plymouth. I thought the latest kernel was supposed to fix the console bug?
<ogra_> not for plymouth
<ogra_> but the installer disables it anyway
<ogra_> and yeah, quantal should work (lubuntu though)
<janimo> I am looking forward to trying lubuntu actually
 * janimo download
<janimo> s
 * ogra_ still fights with allwinner mmc handling
<janimo> ogra_, a new develboard?
<ogra_> zatab
<janimo> ogra_, when did the preinstalled image links move?
<ogra_> move ?
<janimo> well they moved under lubuntu
<janimo> instead of toplevel daily-preinstalled
<ogra_> yes, with the switch to the flavour they end up there automatically
<ogra_> toplevel is reserved for ubuntu indeed
<marvin24> janimo: I didn't figured out yet why it doesn't resume, but we need a r16 kernel to quantal
<marvin24> so I guess it's ok to make package
<ogra_> ++
<marvin24> don't know what's the plan with precise though
<janimo> marvin24, sure, I agree we need the latest, just did not know how much testing it has already
<marvin24> I didn't got much feedback
<marvin24> we can fix minor bugs later, given that there will be no major updates to the r16 series anymore
<ogra_> yeah
<janimo> oh, the 90's
 * janimo just booted up lubuntu for the first time ever
<plars> ogra_: heya
<ogra_> yo
<plars> ogra_: so the .bak files are *not* empty
<ogra_> thanks so much for the bug :)
<ogra_> o_O
<ogra_> how can that be
<plars> ogra_: all of the .bak files there were the same as the original, except for uInitrd of course
 * ogra_ doesnt get where they come from ... looks like f-k was run multiple times durign the install
<plars> ogra_: just to confirm, am I right in thinking that the issue with f-k not installing u-boot.bin and mlo back into the boot partition should be fixed already in todays image?
<ogra_> dunno, only if there is a .1 i guess
<ogra_> i uploaded it ~5h ago, but i dont know if anyone has re-spun the images since
<plars> ogra_: ah, ok I see the upload now
<plars> ogra_: it was unclear to me for a moment if it had already been fixed, or what
<plars> I don't think so
<plars> *I don't think there's been a respin since
<ogra_> it has been fixed, but images need rebuilding
<plars> yeah
<ogra_> (and since its in the live-installer udeb it might be that a d-i upload is also needed)
<ogra_> i'm not sure if l-i gets pulled in at the build or loaded only later
<rsalveti> ogra_: any reason why the daily is not compressed anymore?
<ogra_> rsalveti, you mean img.gz ?
<rsalveti> ogra_: yup
<ogra_> vs .img
<ogra_> because there isnt much you can squeeze out of a squashfs :)
<ogra_> by gzipping it
<ogra_> read: the contents are compressed nowadays ... so we dont need to compress the image
<rsalveti> ogra_: 725M -> 648M
<ogra_> pfft
<rsalveti> still a few megabytes :-)
<ogra_> i'm willing to pay 70M for easier installation
<ogra_> not having the zcat to gunzip mess is worth that
<ogra_> (and not having to maintain a hack to the default image building)
<ogra_> with the switch to live images we dropped all hacks ... i dont really want to introduce any arm hacks again just to save that bit ... i doubt we have users that have SD cards smaller than 1G
<rsalveti> ogra_: haha, ok, you convinced me :-)
<sauerbraten> I wonder if it would be a lot faster to install 300MB of packages using chroot on an i5 than doing it on the pandaboard itself
<ogra_> well, your limit is usually the SD :)
<ogra_> if your I/O is faster on your PC, sure then
<sauerbraten> yeah that's true unfortunately. I doubt that it's faster on the PC. are there big differences in SD card speed?
<ogra_> not major, no
<ogra_> you wont get above 15-20M/s anyway
<ogra_> thats why we dropped that type of image in 12.10
<sauerbraten> what type of image?
<ogra_> SD card images
<sauerbraten> oh
<ogra_> from 12.10 on we only provide live and alternate (as x86 does)
<ogra_> with USB disk as suggested target device
<sauerbraten> there is a desktop preinstalled image for armhf though
<sauerbraten> http://cdimage.ubuntu.com/daily-live/current/
<ogra_> thats not preinstalled
<sauerbraten> oh, right.
<orated> Hi! Which command can give me details about audio device used in BeagleBoard XM? (Like how lspci does on x86)
<ogra_> orated, cat /proc/asound/cards
<ogra_> (like on every other linux)
<GrueMaster> sauerbraten: Did the server image work for you yesterday?
<sauerbraten> GrueMaster: yes it is still running strong and currently installing xubuntu-desktop
<sauerbraten> I had to use chroot to install the wpasupplicant package though
<sauerbraten> why does the server image support WEP but no WPA2? who in there right mind would still use WEP?
<GrueMaster> Hmmm.  Odd.
<ogra_> i guess the assumption is simply that you dont use WLAN on servers so its not well maintained
<orated> ogra_: hardware* details for on-baord audio CODEC used in XM. Like how lspci -vv or /proc/cpuinfo or lsusb does for hardware detected
<GrueMaster> While I admit I haven't tested anything Ubuntu related since March, I had a test for wifi on a netinstall image that worked during early 12.04-alpha.
<ogra_> orated, cat /proc/asound/cards
<orated> well. Ok
<ogra_> or read dmesg :)
<orated> thanks
<GrueMaster> orated: The beagleXM doesn't have any interface like pci that makes device discovery easy.  And iirc, audio is connected to the i2c bus, which is even more fun.
<ogra_> most arm boards dont have pci
<orated> Yes, there is no PCI which is why asked how it detects
<ogra_> (though thats slowly changing with arm server boards appearing)
<orated> Ah-ok
<GrueMaster> Even on x86, audio is on a separate bus (HD Audio bus).  That bus is run off pci, but even on x86, lspci will only show you HD Audio, not the actual audio device spec.
<ogra_> GrueMaster, why did you leave ubuntu-arm ?
<orated> GrueMaster: Yep, thanks.
<ogra_> not owning any arm devices anymore  ?
<ogra_> :)
<ogra_> (talking about the team here)
<GrueMaster> ogra_: Why should I stay?  My working knowledge is dwindling fast.  And I still have my panda pool (although it is down to 6 systems).  But they are mostly idle, just running SETI.
<GrueMaster> And I don't have time (or much desire) to do anything else with them.
<ogra_> well, you still support people here etc
<ogra_> your decision though
<GrueMaster> Only because it is the right thing to do.  But as new releases come out, my support will lessen.
<GrueMaster> Having all of my wiki documents slowly being clobbered by incompitence doesn't help with my disposition.
<ogra_> haha
<GrueMaster> For example, http://wiki.ubuntu.com/ARM/Server/Install.
<ogra_> yeah ...
<ogra_> territory of the server team
<ogra_> i dont step in there anymore :)
 * ogra_ goes for a coffee
<GrueMaster> My point exactly.  There stopped being an Ubuntu Arm team in February.
<GrueMaster> Besides, I'm not thrilled by the current direction Ubuntu is heading.  Bug 1054282 is but one example.
<ubot2> Launchpad bug 1054282 in unity-lens-shopping "No obvious way to restrict shopping suggestions from displaying adult products" [Undecided,Confirmed] https://launchpad.net/bugs/1054282
<orated> ogra_: I can see omap3beagle listed in cat /proc/asound/cards but there is nothing like snd-soc-omap3beagle in lsmod, is that how it should be?
<GrueMaster> orated: Check /boot/config-* to see if the driver is created as a module (=m) or built in to the kernel (=y).
<GrueMaster> If it is built in, it will not show up in lsmod.
<orated> GrueMaster: CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE=y. Thanks! What is /boot/config-* file?
<GrueMaster> That is the kernel config used to build that kernel.
<sauerbraten> how can I get 720p or even 1080p video running on the omap4 server installation with xubuntu-desktop? btw: works like a charm, GrueMaster
<GrueMaster> sauerbraten: I think if you install the omap4 powervr stuff, you should be able to get working video playback.  It used to be in a ppa that was added to your source.list by a script and icon on the ubuntu-desktop.  Let me see if I can find it.
<sauerbraten> mhm I even think it is installable using jockey (that additional drivers dialog) at least ubuntu offered it to me. let me check
<GrueMaster> sauerbraten: Try installing the ti-omap4-software-channel package.
<sauerbraten> ah dang, still installing some gstreamer plugins
<GrueMaster> That should allow you to enable toe ppa.
<sauerbraten> k I'll give jockey a go first though, that seems more stable to me :)
<GrueMaster> I think Jockey will need the above package installed first, but I could be wrong.
<GrueMaster> Well, this can't be good.  My remote ssh to my home system is down.
<sauerbraten> I will try. Also, sound worked out of the box, at least on HDMI. alsamixer shows me the default "Panda" device too, but pulse doesn't. playing anything on the "panda" device using vlc fails though
<GrueMaster> Not a network issue, as I am running Quassel Core on another system (hence my irc presence).
<GrueMaster> sauerbraten: That is a separate issue (that I resolved numerous times).  I think there is a bug filed on launchpad.net for each release.
<sauerbraten> GrueMaster: ok. I added ti-omap4-software-channel, but jockey didn't give me anything. anyway, the update manager bugged me about updates which I am now running, those include the linux-omap4 kernel
<sauerbraten> hopefully that won't wreck the system again (it did with a minimal ubuntu image I tried yesterday)
<GrueMaster> sauerbraten: There may be some other steps to take.  I can't remember and I have no access to a system currently to test with (remote ssh is down).
<sauerbraten> how do I install the pvr-omap4 driver when jockey doesn't find it and ti-omap4-software-channel doesn't  help?
<sauerbraten> also, I have ti-omap4-ppa and ti-omap4-software-channel in my repos, and they conflict with each other
<sauerbraten> I found that ti-omap4-ppa added a file /usr/share/app-install/channels/ti-omap4-ppa.list containing the ppa repo line but "oneiric", not precise. how does that package come into my repos?
<sauerbraten> mhm, I think I solved it. cleaned up a mess of sources and am now installing ubuntu-omap4-extras. we'll see what that does
#ubuntu-arm 2012-09-26
<brendand> what's the deal with xrandr on ARM (specifically Pandaboard)?
<ogra_> what should be the deal ?
<plars> ogra_: hi!
<plars> ogra_: strange thing I just noticed while doing the latest install on panda
<plars> ogra_: when the screen blanks, it goes white instead of black
<ogra_> tell me
<ogra_> intresting
<ogra_> i'm sitting next to a running install where the screen just blanked to black the second where you typed that
<ogra_> plars, desktop or server ?
<plars> ogra_: desktop
<ogra_> hmm
<ogra_> i would blame pvr-omap4
<ogra_> or ypur monitor
<ogra_> *your
<ogra_> its definitely black for me
<rsalveti> plars: that's dpms acting weird with the latest kernel changes
<rsalveti> most of the times it behaves correctly, but I also got a green and white screens sometimes
<ogra_> we could call it a "color test feature" ;)
<ogra_> "while you are not working, ubuntu tests the color cabilities of your monitor for you" :)
<plars> hah
<ogra_> but in a more serious world, that should be filed as a bug indeed :)
<ogra_> low prio etc
<highvoltage> sounds like the original NES which would show full screen (sometimes alternating) colours when things go wrong
<plars> ogra_, rsalveti: desktop seems to be working nicely, known issue with bug #1055949 but it's pretty minor.  And the ui is pretty slow... did we ever get good drivers for panda?
<ubot2> Launchpad bug 1055949 in unity "Unity panel shadow appears as solid black bar on GLES/ARM (Pandaboard)" [Medium,Confirmed] https://launchpad.net/bugs/1055949
<ogra_> thx
<plars> ogra_, rsalveti: looking a little more, audio seems to work over both hdmi, and jack (yay!) however I'm getting a weird popping noise at the beginning of playing a sound when I use the headphone jack
<plars> is that something you've experienced too?
<ogra_> not tried :)
<plars> it's quite a loud pop actually
<ogra_> plars, we ship pvr-omap4 preinstalled, you should be using it from the start on desktop nowadays
<plars> ogra_: maybe I'm just spoiled.. it seems slowish to me
<plars> but I'm just on older panda, no ES :(
<ogra_> mie is still running ...
<ogra_> *mine
<ogra_> will tell you if its slow once its done :)
 * plars is just glad the screen jitters are gone
<plars> ogra_: probably server is a bigger issue at the moment - hggdh seems to hit your hdmi bug, and though my hdmi monitor works fine under server, the keyboard does not so I still have to install over serial
<ogra_> yes, same here
<ogra_> its on my TODO
<ogra_> my screen works just fine now with server though
<ogra_> plars, i bet the slowness you see is because update-apt-xapian-index runs right after boot (for about 30min) and eats all your CPU
<plars> ogra_: ah, could be
<ogra_> my desktop is idle right after install but the USB key blinks like mad
<ogra_> oh, and apport usually grinds the system to a halt as well
<ogra_> seems it just collected info for a gwibber crash for 15min here
<sauerbraten> after installing ubuntu-omap4-extras, do I need to install a h.264 decode package or something? or is there a specific way I have to start video playback? shouldn't firefox be able to play h.264 e.g. on youtube?
<ogra_> better ask that to the TI guys in #pnadaboard
<ogra_> *pandaboard
 * ogra_ hasnt used the PPA since oneiric or so
 * ogra_ goes for a break
 * sauerbraten will try totem
<ogra_> plars, ha ! now my screen was white too ... it seems to be related to running unity ... before i wasnt logged in
<sauerbraten> my X fails to use the correct driver. what do I need to put into xorg.conf? I had Driver set to "omap", which it can't find (said xorg.o.log) and "omap_pvr" (which made it look for omappvr, also not found) modprobe -l shows me "updates/dkms/omapdrm_pvr.ko"
<sauerbraten> is there any way to find out the correct string to put as driver so it loads the correct one?
<ndec_> sauerbraten: "omap" is the right name. so there must be some other problem
#ubuntu-arm 2012-09-27
<janimo> ogra_, I uploaded a new ac100 kernel last night, it is waiting for approval
<hrw> which version of kernel you guys use on ac100?
<ogra_> 3.1.something
<ogra_> i think .10
<janimo> hrw, 3.1.10 from nvidia
<janimo> hrw, they have various 3.1 based branches with heavy churn among them inside arch/arm/mach-tegra and related drivers/
<janimo> infinity, around? Can you let the newest ac100 kernel upload through? thanks
 * ogra_ guesses we'll have to wait until the freeze is lifted
<ogra_> or did you push to -proposed ?
<janimo> ogra_, no, plain archives. Forgot about -proposed
<janimo> or rather I never really knew what the current approval/freeze process had become
<janimo> if it is more automated due to -proposed being a queue which is flushed after freeze I'll remember it for next time :)
<janimo> so universe is frozen not because it could affect images but because it can tie up builders?
<ogra_> well, the pieces that are on the images that you dont want in the archive during a freeze (i.e. that you dont want to distrub the image testing with) should go to proposed
<janimo> ogra_, oh forgot that universe bits go to images. Anyway I usually do not upload the kernel meta so it can be tested without being automatically upgraded to immediately
<ogra_> yeah
<ogra_> and the freeze should eb gone real soon now
<ogra_> hmm ..
<ogra_> bazaar.launchpad.net/~ubuntu-branches/ubuntu/breezy/xscreensaver/breezy/view/head:/debian/patches/01lockscreen.dpatch
<ogra_> i wonder if i should spend some hours on the weekend with that
<xnox> ogra_: is this page http://www.ubuntu.com/download/arm correct?
<ogra_> looks ok, yes
<ogra_> we should probably make the desktop link less arch specific at some point
<xnox> ogra_: any updates to "supported" platforms list?
<ogra_> omap4 ...
<ogra_> thats is
<ogra_> it
<ogra_> for the server side, ask the server guys :)
<xnox> what about AC100 ?
<xnox> os is that community?
<phh> http://cdimage.ubuntu.com/releases/12.04/release/ it's there
<phh> just not documented
<ogra_> and not canonical supported
<ogra_> yeah, its community
<xnox> ok.
<ogra_> everything on desktop is community but the panda
<ogra_> same for server plus highbank and armadaxp
<ogra_> i think
<hrw> even when it was done by canonical people
<ogra_> hrw, "spare time work" :)
<hrw> ;))
<bizulk> Hello world ! I've just install ubuntu precise on beagleboard xM, followed the step to install and test DSP acceleration. But /etc/init.d/dsp start result  in FATAL : module tidspbrdidge not found. Shall I compile kernel and the module by myself of is there a way to directly download it ?
<ogra_> "followed the step to install and test DSP acceleration" > did you find that on an ubuntu wiki ?
<bizulk> http://elinux.org/BeagleBoardUbuntu#DSP
<ogra_> well, talk to the people maintaining that wiki
 * ogra_ doesnt think the ubuntu kernel has any DSP support, our omap3 kernel is plain mainline
<bizulk> ogra_: 3.2.0 kernel has  if compiled for it.  but I can't even check it as the /proc/config.gz is missing.
<ogra_> it is in /boot
<ogra_> (as for all ubuntu kernels, no matter what arch)
<bizulk> oh yes your're right and... well the tidspbridge is not set
<bizulk> maybe in the repo there a compiled kernel supported for it. I don't want to mix ubunt stuff with things I get from the net you known
<RoyK> bizulk: you can turn on /proc/config.gz in the kernel config before you build it, but afaik ubuntu doesn't do that by default
<ogra_> right, since we ship it as a textfile in /boot already
<ogra_> bizulk, if its in mainline already and just needs enabling, file a bug and point ppisati to it
<ogra_> flipping an existing config option is surely possible
<bizulk> RobertCNelson is the one that write the wiki. Whi is ppisati ?
<ogra_> ppisati, is the ubuntu kernel maintainer for arm kernels
<ogra_> he is the master of the configs :)
<bizulk> ok. Maybe I shall before upgrade since I see in the package list some kernel stuffs...
<ogra_> sure, but dont expect that the option was switched one or so :)
<sveinse> What can I do to speed up apt-get dist-upgrade? I'm running on omap3 with sdcard system, and dist-upgrading from natty to precise takes 40minutes!
<ogra_> only 40 mins 1
<ogra_> !
<hrw> sveinse: only 40 minutes?
<sveinse> ok, I think I'm in the wrong school :P   Management wont accept this, and 10 minutes would be more like it
<ogra_> you must have a really fast card or a really small system
<ogra_> dist upgrading an SD based  system with a desktop installed i would rather measure in hours than in minutes
<sveinse> small system, I guess. Card's about 3-4Mb/s in write speed. The sum of all debs are about 170megs
<ogra_> how much of these 40min is download time ?
<sveinse> none, or out of scope of this. We deploy the debs in a container which the user puts on a USB device and puts in the device
<ogra_> ah
<ogra_> well, for a 3-4M/s device thats definitely pretty fast
<sveinse> Hmm, I'll say that to my project manager :P Speak with the guys in #ubuntu-arm. LOL
<ogra_> i'm surprised the system is usable wrt app startup times on such a blockdev
<sveinse> Well thats another issue. We have 40 secs from power to functional GUI. Also too long
<ogra_> pretty good for such a device
<sveinse> I did a bootchart, and its either cpu-bound or IO-bound. Plain busy all of the time
<ogra_> yeah
<ogra_> unlikely that you can suqeeze more out of that
<sveinse> yup. And I'm starting to feel that perhaps Ubuntu and a deb based distro wasn't the right thing for this little embedded thing
<ogra_> well, ubuntu and debian are general purpose distros ...
<ogra_> doing embedded with that is hard
<ogra_> (ask the emdebian guys :) )
<sveinse> Because, coming back to my original question, there is nothing you can do with dpkg to speed it up? Some area to use tmpfs in, allow it to cache, anything?
<sveinse> Oh yeah, I know about this. Given my now soon to be two years of adopting cross compilation with debian packages
<ogra_> well, i'm working on an actual embedded filesystem builder over here (spare time project) ...
<ogra_> with luck it might m,ake 13.04
<sveinse> Two main reasons for picking Ubuntu btw: 1) Large base of pre-compiled apps, 2) armv7 support out of box, now armhf as well
<sveinse> And 3) selecting a deb based distro, as deb is a great tool for distributing updates
<ogra_> well, packaging systems are quite some overhead on embedded ...
<GrueMaster> sveinse: If you are using this for development, I recommend using a USB device for root.  Much faster than an SD (as much as 10x).  For final deployment, SD is ok, as minimal updates are required.
<sveinse> GrueMaster: Point is that we have a couple of thousand units on the market with natty. We want to upgrade these to precise and the HW cannot boot from USB
<GrueMaster> Ah, field upgrade.  Actually, the way I did it was to use the SD for /boot and a usb drive for rootfs.  But in this case, not sure what to tell you.  Maybe script it to reboot to a console only (no X) runonce script that performs the update.  Less overhead that way.
<sveinse> (Not intending to troll, but) Would you guys accept that your mobile phone or pad take 40 minutes to do an OTA upgrade?
<ogra_> nope
<ogra_> oh, wait update
<ogra_> yeah
<GrueMaster> Actaully, my Droid 2 Global did when it went from 2.2 to 2.3.
<GrueMaster> And it is essentially the same HW as the BeagleXM.
<ogra_> 40min for an OTA update is fine imho
<GrueMaster> Same with my Nook Color.
<ogra_> as long as the device tells me in advance
<ogra_> and lets me postpone until i have time to do the update
<GrueMaster> Yes.  User controlled upgrade.
<ogra_> if it doesnt tell me "it takes a few munites" but then goes on for 40
<ogra_> *minutes
<sveinse> Oh, I'm struggling with an interesting "feature" here. We've implemented a udev hook to look for upgrade files when an USB device is inserted.
<ogra_> and whats your prob with it ?
<sveinse> That has worked fine very long, but now it fails miserable. What do you think happens to the processes started by udev when udev is upgraded ;)
<ogra_> ah, yeah
<sveinse> It simply cuts the upgrade in the middle of everything. I mean, there are like four nested script and they are cut off like they never existed
<GrueMaster> Sounds like you should be doing a two-stage upgrade.  Stage one is triggered by udev ( copies run-once scripts over, deletes or moves triggering mechanism), stage two does the actual upgrade.
<sveinse> Yes, I was experimenting with using disown in bash to fork off the upgrade, but apparently its killed then. It probably still belongs to the same process group
<sveinse> I'm going to try to use setsid. If that fails, then I'm going for a solution similar to GrueMaster's proposal
#ubuntu-arm 2012-09-28
<sveinse> Does Ubuntu/Debian have any mechanism for deferring some action after next reboot and not more than once?
<ogra_> janimo, kernel build failed :(
<ogra_> (it seems to use Werror ?!?)
<ogra_> oh, only -Werror=maybe-uninitialized
<ogra_> janimo, http://paste.ubuntu.com/1247107/ i guess we should drop all these hardcoded -Werrors ;)
<janimo> ogra_, I am on it. I built using 4.6 and worked fine :(
<janimo> 4.7 is pickier
<janimo> I cross-built on precise forgetting there may be toolchain issues if uploading to quantal
<janimo> I hate it when I need to bump the ABI with no .deb available and have to do the manual creation of those files and dirs
<janimo> ogra_, lots of Werrors in the tegra kernel btw. I'd keep them there thougg but I'll pay more attention when testing the build
<hrw> http://marcin.juszkiewicz.com.pl/2012/09/28/lets-take-a-look-at-arm-boards-again/ - opinions?
<bizulk> hi ! has the ubuntu-arm been installed on commercial device lie : archos 32,43 or other omap based mobile devices
<ogra_> janimo, well, according to ppisati thats not usual in kernel builds
<LetoThe2nd> hrw: opinion: 500 - Internal Server Error
<suihkulokki> likewise
<ogra_> janimo, i would drop them, in case anyone rebuilds with an exotic toolchain
<janimo> ogra_, probably makes sense. No idea. Don't these catch actual bugs as in userspace code?
<janimo> Or enforce some coding conventions. Some are really picky I agree.
<ogra_> usually warnings arent errors :)
<hrw> checkng
<LetoThe2nd> bizulk: should be doable. archos even offers an "open" bootloader.
<ogra_> and kernel builds always spill warnings
<LetoThe2nd> bizulk: there also are positive reports, but no "1-2-3 click here, done" guide.
 * ogra_ hugs ppisati for the fixing of bug 1045855
<ubot2> Launchpad bug 1045855 in linux-ti-omap4 "usb keyboard doesn't work during installation of ubuntu-server on panda" [High,Fix committed] https://launchpad.net/bugs/1045855
<ogra_> was the udeb actually missing ?
<ogra_> hrw, "Error establishing a database connection" over here
<suihkulokki> it's available on planet.linaro.org tho
<ogra_> yeah, i read it on my tablet during the coffeebreak i just had ... there it worked fine
<ogra_> using the link from g+ though
<suihkulokki> hrw: you should mention on that the A10 is not only lacking in mainline kernel, but also no public documentation either
<ogra_> there is
<suihkulokki> url?
<ogra_> (me is just fighting with some 100% chinese PDFs)
<suihkulokki> ...from the dark alleys of the internets
<ogra_> ugh, no idea anymore, its for the script.bin stuff though ... butu googling definitely got me other pdfs too
<hrw> suihkulokki: add comment?
<ogra_> if you want that one i can push it somewhere
<hrw> once I get mysql working again
<suihkulokki> ogra_: doesn't count as public docs.. more like leaked docs.
<ogra_> heh, ok
<ogra_> yeah, might be leaked ....
<ogra_> their way of doing their own devicetree type of thing is really annoying
<LetoThe2nd> hrw: i know that its not really in the dev board scene already, but what about all that marvell stuff?
<ogra_> ++
<ogra_> once there are armadaxp boards that workstation thing should be possible
<LetoThe2nd> i mean, they pretty much always have the desired sata.
<LetoThe2nd> its just that the widely available stuff from them is still armv6/armv5
<ogra_> the armadaxp's i have seen even take normal dram
<ogra_> xp is v7
<suihkulokki> no gpu or even framebuffer on armadaxp
<LetoThe2nd> ogra_: is there already an affordable kit?
<ogra_> quad core 1.2GHz
<ogra_> suihkulokki, PCI slots ;)
<LetoThe2nd> suihkulokki: what would i need that for?
<ogra_> LetoThe2nd, i only saw pre-prod
<LetoThe2nd> ogra_: ok, so my assumption "not yet" still holds true.
<ogra_> yeah
<ogra_> but there should be some buyable ones soon
<suihkulokki> ogra_: need x86 emulation for those :)
<LetoThe2nd> i mean, all those cheap qnap mini nas things make nice hackable things after all.
<ogra_> suihkulokki, do i ? i thought the server boards with AXP on them will have them by default
<suihkulokki> ogra_: you are aware how video cards are initialized?
<LetoThe2nd> openrd ultimate has long had pci anyways.
<ogra_> suihkulokki, something you should be able to fake in a driver, no ?
<hrw> LetoThe2nd: openrd is armv5
<LetoThe2nd> hrw: exactly what i said above.
<LetoThe2nd> i just mean that pci on arm is not very far away.
<LetoThe2nd> don't know if marvell is still so bi***ing about documentation, though
<suihkulokki> ogra_: sure, but someone needs to write the code to do so first
<ogra_> indeed
<LetoThe2nd> huh, *write* code?
<LetoThe2nd> why can't we just *download* the codes?
<LetoThe2nd> someone please send me the exact steps!
<ogra_> haha
<hrw> ok, works again
<bizulk> I would like to thanks tu arm-ubuntu community for the DSP integration on OMAP, I'm working on this for 4 Weeks. And finally got the video working on 12.04 (thanks for Robert CN scripts that make a got stuff for downloading a clean kernel image with dsp support). I was going onto this conclusion : "Everybody knows what it is, knows somebody that seen it working, but neved seen it himself neither how to make it works"
<ogra_> bizulk, did you file the bug as i asked you, so ppisati can put it iun the official kernel ?
<bizulk> no still not. I may do it know
<bizulk> where shall I post it ?
<ogra_> on the bugtracker url i gave you last time :)
<ogra_> https://bugs.launchpad.net/ubuntu/+source/linux
<ogra_> 8there is a "report a bug" button on the right
<bizulk> ogra_:ok I do it know
<ogra_> thanks, give us the bugnumber here afterwards
<bizulk> Are we talking about the /proc/config.gz missing file, or the tidspbridge stuff ?
<bizulk> or both
<ogra_> config.gz isnt a bug
<ogra_> (we ship the config as text file already)
<bizulk> that's what I was thinking
<ogra_> well, i told you last time that its on purpose ... didnt change yet  since ;)
<bizulk> I expect the answer to be : this is not a but as gstreamer does not embbed the gst-dsp plugin on the dist
<ogra_> well, if the kernel option can be turned on without issues ... even though we dont have the dsp package you shouldnt need t5o recompile your kernel to use it if possible
<dholbach> hey hey
<ogra_> heh
<ogra_> welcome to the club dholbach
<dholbach> :)
<dholbach> I was wondering if we had some good instructions somewhere to get 12.10 on the Mele A1000 :)
<ogra_> no, but there are community people somewhere with images and install instructions
<LetoThe2nd> miele a1000? a dishwasher?
<ogra_> i'm trying to get an imager for the zatab working before UDS, the a100 shouldnt be to hard to support from that
<dholbach> LetoThe2nd, no, I'm afraid not - http://dx.com/p/mele-a2000-1080p-android-2-3-network-multi-media-player-w-sata-usb-hdmi-lan-vga-wifi-4gb-131566 :)
<LetoThe2nd> dholbach: ah dammit
<dholbach> LetoThe2nd, a dishwasher might make a more interesting news story, I agree :)
<ogra_> http://www.cnx-software.com/2012/04/28/how-to-create-your-own-debian-ubuntu-image-for-mele-a1000-allwinner-a10-based-stb/
<bizulk> ogra_: you're right, recompile it on the omap would be a real pain
<LetoThe2nd> looks nice though. but yet another allwinner.
<ogra_> allwinner isnt that bad ...
<ogra_> that it is a8 is bad :)
<LetoThe2nd> ogra_: hehehe
<ogra_> the same CPU with dual core would be awesome
<dholbach> thanks ogra_ - I'll try that out
<bizulk> ogra_: my god this site signing in process is a big armor
<LetoThe2nd> given the price tag it might be a nice sidekick device indeed.
<ogra_> yeah, the zatab i have here has massive issues though ...
<LetoThe2nd> ogra_: like hdmi not working? ;)
<ogra_> apps often hang in android
<ogra_> due to the CPU being maxed out
<LetoThe2nd> dholbach: do you know how all that storage/interface things are glued to the cpu?
<ogra_> badly :)
<dholbach> LetoThe2nd, I'm afraid I don't
<LetoThe2nd> all usb, i guess.
 * ogra_ tries to get the MMC to work on his zatab kernel since over a week now 
<hrw> ogra_: Allwinner A15 will be dualcore A7 iirc
<ogra_> usb works fien so i can run an ubuntu rootfs ... but i cant convince the kernel to keep the MMC powered on once it booted
<ogra_> hrw, yeah ... will be ... :)
<hrw> ogra_: anyway I keep away from anything in mainline kernel (or on a way to it)
<ogra_> not in mainline you mean ?
<hrw> yes ;)
<ogra_> :)
<bizulk> ogra_: my bug no must be : 1058022
<bizulk> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1058022
<ubot2> Launchpad bug 1058022 in linux "no tidspbridge support in kernel." [Undecided,New]
<ogra_> bizulk, thnaks a lot
<bizulk> ho great stuff this bot. I dream to install such stuff in my office.
<bizulk> (lunch time now)
<ogra_> bizulk, oh, i was hoping you would state the exact options that need to be enabled in the bug so ppisati doesnt need to dig around
<ogra_> bizulk, the page you linked to isnt helpful for finding that option
<ppisati> bizulk: i'll take a look
<ogra_> marvin24, http://paste.ubuntu.com/1247332/ ... not sure whats up with your package cache, but squeak-vm is available for me on all armhf platforms
<marvin24> ogra_: marvin24?
<ogra_> oh, i mixed you up
<ogra_> lol
<ogra_> sorry
<ogra_> ETOOMANYMARCS
<bizulk> ogra_: I'll post the config file
<ogra_> ppisati, ^^^
<ppisati> ogra_: you mean squeak-vm or the config file? :)
<ogra_> the config file, unless you want to add smalltalk support to the kernel now :)
<ppisati> bizulk: add the config diff to the lp bug you just created
<janimo> ogra_, I have uploaded a new ac100 package, I hope it gets through soon and actually builds this time
<ogra_> yay
<doko> ogra_, would you mind looking at the libaio ftbfs? it crashes the buildd machines ...
<ogra_> lets bribe infinity ;)+
<ogra_> doko, i dont see it on http://qa.ubuntuwire.org/ftbfs/
<marvin24> janimo: hey, thanks
<doko> ogra_, https://bugs.launchpad.net/ubuntu/+source/libaio/+bug/1058081
<ubot2> Launchpad bug 1058081 in libaio "libaio ftbfs on armel/armhf" [High,Confirmed]
<ogra_> hmm,. the build seems to work just fine ... but these tests even make my sabre cpu start glowing
<doko> there's a bug report about an invalid test case too
<ogra_> ho can something that builds in 5 seconds take so long for its selftests, tsk
<ogra_> doko, http://paste.ubuntu.com/1247430/
<ogra_> hmm
<ogra_> no issues
<ogra_> doko, where is the ftbfs buildlog so i can compare the two ?
<doko> ogra_, there is none. buildd dies
<ogra_> i can imagine, these tests are really evil
<ogra_> i have no panda set up for building atm, but will try on a panda as soon as i have one ready
<ogra_> doko, the debian/rules file has an uption to pass "nocheck", will anone kill me if i just disable the tests on arm for now ?
<ogra_> *option
<highvoltage> does this boot ubuntu? http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G133999328931
<doko> ogra_, or fix https://bugs.launchpad.net/ubuntu/+source/libaio/+bug/607665
<ubot2> Launchpad bug 607665 in libaio "Invalid test case on ARM" [Medium,Confirmed]
<ogra_> doko, well, that doesnt kill the build
<ogra_> (here)
<doko> ogra_, with a precise kernel?
<ogra_> 3.2.0
<ogra_> we dont have any recent kernel for mx6
<ogra_> (or better: more recent)
<ogra_> thats all quantal
<doko> ok
<ogra_> the failed tests doesnt stop the build for me
<ogra_> and in fact that bit scrolls really fast ... it takes like 10 min for the tests before and after
<ogra_> and i think thats where the buildd is falling over ...
<bizulk> I added to the tidspbridge bug the config file, and particular option in comments
<ogra_> great, thanks :)
<bizulk> I bug is now in triaged state and used the apport-collect tool. Nothing more is needed from me for now ?
<ogra_> yeah, should be fine
<janimo> doko, libaio seems to build for me on ac100/quantal
<janimo> no build logs from the crashing machines?
<ogra_> janimo, apparently not
<janimo> I wonder if it's a kernel issue
<doko> no. I could give it back, and you could poll the build log while the build is running ...
<ogra_> just waiting for my quantal panda to finish
<ogra_> looks pretty good yet
<janimo> although I am suspecting something weird. my build took a few imnutes
<janimo> whereas LP shows 8 hours for previous builds
<ogra_> janimo, the build or the tests ?
<janimo> debuild -us uc
<janimo> -uc
<ogra_> my build (even on a panda with a really slow USB key) is done in under a minute
<ogra_> oh, i just use dpkg-buildpackage -rfakeroot -b
<ogra_> in the souorce tree
<ogra_> the tests take between 10 and 30min though
<janimo> I wonder why this is 8 hours then? https://launchpad.net/ubuntu/+source/libaio/0.3.109-2ubuntu1/+build/2964075
<janimo> maybe some tests fail early and do not proceed here
<ogra_> might be
<ogra_> in any case failing tests dont seem to stop the build anyway
<ogra_> even the precise log has the failures
<janimo> indeed
<ogra_> so i bet we could as well disable them :)
<ogra_> dh_testdir
<ogra_> /usr/bin/make
<ogra_> /bin/sh: 1: git: not found
<ogra_> /bin/sh: 1: lsdiff: not found
<ogra_> make[1]: git: Command not found
<ogra_> heh
<janimo> on LP/armhf I think the timeout of 8 hours or something similar kicked in. Or just some obscure bug. The build+tests are short
<janimo> ogra_, yes, it just checks whether it's in a git repo
<ogra_> seems that log doesnt care at all if *anything* fails
<janimo> can be ignored, it took just as little time with git installed
<ogra_> k
<janimo> so maybe a lucid kernel or whatver the builders have is the issue
<ogra_> precise
<ogra_> but yeah, very likely
<ogra_> the precise panda kernel wasnt particulary great
<ogra_> (dieing on idle etc)
<ogra_> wow, that 14.p test takes a century
 * ppisati goes out to run an errand, brb
<ogra_> hmm, whatever that test does, it hits the disk realyl hard it seems
<ogra_> was probably not a good idea ro try that build on my slowest USB key
<ogra_> *to
<ogra_> heh, so my panda has a load of 5 and the test eats up all memory
<ogra_> i can imagine that might fail with anot 100% correct kernel
<ogra_> *a not
<ogra_> doko, libaio just finished on my quantal panda (fresh desktop install from wed.)
<ogra_> so i would say its clearly the buildd kernel
<doko> please leave a comment in the bug report
<ogra_> will do
<ogra_> done and buildlog attached for that one as well
<bizulk> I have installed the xorg omapfb driver but Xorg doesn't seem to use it : sudo apt-get install xserver-xorg-video-omap3
<ogra_> you might need an oxrg.conf, not sure
<ogra_> that package comes from debian as is
<bizulk> xvinfo --display :0.0: still returns 'no adaptors present
<bizulk> Where shalll be this file ? I don't remember
<ogra_> in /etc/X11
<ogra_> ubuntu doesnt use that file anymore by default so you might need to create it
<bizulk> ogra_: I'll check it
<ogra_> probably the package ships an example
<bizulk> no it has not :(
<bizulk> well the wiki presume that the driver is automatically loaded but I could not figure how without a Xorg.conf file
<ogra_> check the log :)
<bizulk> I did
<ogra_> well, all i know about this package is that it has been removed in 12.10
<bizulk> why ? does it mean that the Xorg video driver is not anymore part of it ?
<ogra_> it is a hacked up xfbdev driver nobody maintains afaik
<ogra_> and isnt compatible to abi 13 anymore
<bizulk> Does Angstrom not use it (or won't) neither.
<ogra_> no idea
<ogra_> we dont do much with oma3 here anymore
<ogra_> *omap3
<ogra_> but once angstrom updates to the current xorg abi they will likely have to port it if they use it
<janimo> ogra_, although interestingly it builds on ac100 quantal which has a 3.1 kernel
<janimo> panda precise is 3.2 right?
<ogra_> janimo, well, the precise panda kernel has issues
<ogra_> we know it dies idling on some boards for example
<janimo> are there any non-panda builders left?
<ogra_> nope
<janimo> where are the slow crappy boards when you need them???
<ogra_> but i would just propose to backport the quantal kernel and be done
<ogra_> you could try on the porter box, i think that still runs a natty kernel
<janimo> ogra_, if you install the precise kernel in quantal it should fail if that is the cause right?
<janimo> I think the porter box has long been dead
<ogra_> yep
<ogra_> no, i heard its back
<janimo> at least I could not connect to scheat for a long time, so gave up
<ogra_> scheat
<janimo> ok, did not check in the past two months I guess
<ogra_> i didnt check at all, Daviey claimed its back on #ubuntu-devel
<ogra_> and i trust Daviey blindly :)
<bizulk> aie : it seems that Xorg didn't like my conf
<ogra_> janimo, linux-ac100 is in ... time for meta i guess
<janimo> yes, but should need at least a test first
<janimo> I'll install
 * ogra_ cant ... else i break my screen
<janimo> and in as in past NEW?
<ogra_> well, cjwatson just said he processed it in #ubuntu-release
<janimo> ah ok
<ogra_> so past NEW i would think
<janimo> ogra_, uploaded
<ogra_> thx
<janimo> ogra_, are you planning the graphics driver upload for next week?
<ogra_> or the weekend, yeah
<ogra_> and if i manae in time also the codecs
 * ogra_ has to rush to the vet now ... back in ~1h
<bizulk> hi ! boot.scr is a binary file ?
<bizulk> how do we edit that stuff ?
<bizulk> okay it's in the host with mkimage
<lilstevie> bizulk, you don't edit the boot.scr directly, you edit the boot.cmd and then make it into a boot.scr with mkimage
<GrueMaster> It is actually a text file with a 72 byte crc blob.
<GrueMaster> You can strip the first 72 bytes, then edit it as a text file (boot.script).  TO recreate the CRC (needed by u-boot), use "mkimage -A arm -O linux -T script -C none -d boot.script boot.scr".
<GrueMaster> (I used to have this documented on http://wiki.ubuntu.com/ARM but it has since been either deleted or moved by others.
<bizulk> there is not other way to put off the splash screen ? well okay
<GrueMaster> Sadly, not easily.  You could interrupt uboot via serial console, but that is a pain.
<lilstevie> bizulk, the process may sound hard/scary but it is pretty straight forward
<lilstevie> (modifying the boot.scr)
<bizulk> lilstevie: first of all, new for me :) (but it was just for having debug message on screen/serial as the xorg omapfb bug the boot process)
<GrueMaster> The easiest way to strip the file for editing is with "dd if=boot.scr of=boot.script bs=72 skip=1".  Then you can edit it and use the above mkimage command to re-bless it.
<bizulk> GrueMaster: how do you strip the bytes ? dd ?
<lilstevie> bizulk, GrueMaster gave you the command there :)
<GrueMaster> Yes.  YOu can also do it with a text editor, but it isn't as clean.
 * GrueMaster notices shift key is sticking again and grumbles profusely.
<bizulk> ho ! sorry I did not see the cmd just below
<bizulk> I see that uEnv.txt is still supported
<bizulk> I have strip off quiet and splash, but I've just got a black screen with a penguin :d
<bizulk> the xorg omapfb driver seems to be loaded but I do think I have to pass more option to activate DVUI output
<GrueMaster> If you want earlier kernel messages and boot messages to go to the serial console, add "earlyprintk=ttyO2,115200 console=ttyO2,115200 console=tty1"
<bizulk> ho yessss
<bizulk> I did put the console in bootargs without results
<bizulk> is "xf86-video-omapfb" an alternative to omapfb ?
<marvin24> janimo: I'm trying to compile your kernel - do you know how to enable ccache in kernel builds?
<janimo> marvin24, cross compiling?
<marvin24> yes
<marvin24> there must be some magic string added to debuild
<janimo> ah, I do not use that. Ijust have /usr/lib/ccache/arm-linux-gnueabihf-gcc -> ../../bin/ccache as symlink
<janimo> so it is systemwide not specific to kernel builds
<janimo> and I never checked that it actually works :) The builds seem fast though
<marvin24> yes, the problem is it doesn't
<marvin24> but the man page says use --prepend-path
<marvin24> lets try it
<marvin24> no luck :-(
<janimo> no luck as in nothing is put in ~/.ccache?
 * janimo checks
<marvin24> yes
<marvin24> neither symlink nor --prepend-path works
<xnox> installing armhf
<xnox> had to do a tty1->tty7 dance to view X
<xnox> maybe i was impatient for ubiquity to come up though.
#ubuntu-arm 2012-09-29
<janimo> infinity, do you think the drivers should be purged even from git history or a regular removal commit should be ok? Is having them in .git considered redistribution?
<ogra_> root@ubuntu:~# du -hcs /
<ogra_> 7.0M	/
<ogra_> yay
 * ogra_ fiddles with his embedded rootfs builder
<highvoltage> what's that on, ogra_?
<ogra_> vm
<ogra_> the target is that the tool will build you a tarball with an embedded fs
<ogra_> no matterr what you run it on, it should work
<ogra_> and the core rootfs shouldnt be larger than 10M (with upstart. udev etc)
<ogra_> the system will be truely embedded thoguh, no package manager or anything
<Guest9216> I am using ubuntu-desktop on beagleboard-xm, is there any SDK that works on it?
<Guest9216> what package do I need to install  to my ubuntu (laptop) for the toolchain of beagleboard-xm (ubuntu-arm)? is it gcc-arm-linux-gnueabi ?
<ogra_> well, rather gnueabihf
<ogra_> (unless you actually want to produce armel stuff which is rather dead)
<Guest9216> I want to compile my C code on beagleboard-xm by using eclipse or Qt-creator
<Guest9216> I am looking for the tool chain for it, do you suggest me to install gcc-arm-linux-gnueabihf ?
<Guest9216> uname -a outputs "Linux beagleubuntu 3.2.0-26-omap #41-Ubuntu Thu Jun 14 18:19:55 UTC 2012 armv7l armv7l armv7l GNU/Linux" on the beagleboard
<ogra_> well, for compiling a kernel or so the gcc package should be enough ...
<ogra_> as soon as you start doing things that need dependencies a chroot is way better
<Guest9216> are gcc on my laptop (ubuntu-12.04) and gcc on beagleboard-xm(ubuntu-desktop) the same?
<ogra_> if your release is the same on both
<ogra_> the gcc for all arches in ubuntu is built from the same source package so your x86 one as well as the cross one as well as the native one on the beagle itself are identical within one release
<Guest9216> now I see. thank you ogra_
<ogra_> 90% of the software you write you can just develop on x86 ... unless its highly HW specific probably ... and then just rebuild it for your target arch if you are done
<ogra_> the same as for gcc above is usually also true for libs etc so you have the same APIs on both arches
<Guest9216> thanks a lot
<infinity> janimo: If there's a sane way to rebase them out of existence in the git history, that would be better.
<infinity> janimo: One of the drivers isn't even something that Marvell *can* give you permission to redistribute, since the copyright belongs to one of their partners, not them.
<mogh> Hi, i want to get ubuntu running on my Gooseberry board
<mogh> but all i can find is that i should extract an image onto my microSD card, but i can't seem to find any images anywhere..
<mogh> Are there any tutorials or other resources on how to go about this?
#ubuntu-arm 2012-09-30
<IamTrying> Is Ubuntu 12.04 available for Asus Tablet?
<lilstevie> IamTrying, officially? no
<lilstevie> but specifically which asus tablet
<IamTrying> lilstevie, no problem. Asus Tablet Eee pad transformer
<IamTrying> I have old Ubuntu installed but its touch is not working.
<IamTrying> lilstevie, ^
<lilstevie> touch sounds like something else
<lilstevie> cause any version of ubuntu that I have released an image of has working touch
<lilstevie> just fwiw
<IamTrying> lilstevie, 12.04 do you have ? I want to test today
<lilstevie> no
<IamTrying> OK - then i have problem, i have to reverse to Android
<lilstevie> you could always try that netinstaller that someone did
<IamTrying> OK
<IamTrying> lilstevie, i did it almost year ago, i am not sure if this was the valid link if you may know? e.g: http://lilstevie.geek.nz/ports/OLiFE-Prime-Edition.tar.gz
<angs> what is the latest gcc version to download for "apt-get install gcc-4.6-arm-linux-gnueabi" ?
<janimo> IamTrying, touchscreen or touchpad is not working on the transformer?
<angs> which one is for beagleboard-xm arm-linux-gnueabi or arm-linux-gnueabihf?
<IamTrying> janimo, actually all working but i have to use OLiFE manually to bring the virtual keyboard for Ubuntu (physically touchscreen working well)
<IamTrying> the problem is i need Ubuntu 12.04 (the old one is not stable, it breaks my apps)
<janimo> IamTrying, ok. No experience with Olife myself
<IamTrying> janimo, Well thats the best one, ever worked.
<ogra_> angs, gnueabi = armel, gnueabihf = armhf ... depends what your beagle runs :)
<angs> armhf, thank you ogra_
<lilstevie> IamTrying, I would be a little worried that 11.10 apps are breaking all of a sudden
<IamTrying> lilstevie, yes it is, for audio capture and video capture 12.04 is most stable in my case.
<IamTrying> lilstevie, i used OLiFE long time ago, and i was using it. But few months ago it was crashed, without any reason, like it was rebooting over and over. I did not had time to fix it, so today again reinstalling it. FYI.
<IamTrying> Is it normal OLiFE taking more then 2 hour to install the dual option? Still its ....
<IamTrying> Put your device in APX mode then press any key : did ....."more then 2 hour left.."
<lilstevie> pastie the whole output cause no
<IamTrying> lilstevie, https://gist.github.com/3806921
<lilstevie> did you press... well any key
<IamTrying> Enter the first one
<lilstevie> cause as far as that log is concerned you haven't
<IamTrying> lilstevie, i did Enter, space or a b bla bla...
<IamTrying> but still more then 2 hour gone, saying nothing....
<lilstevie> yeah it actually says something, and so should your tablet
<lilstevie> try running nvflash on its own
<IamTrying> lilstevie, Thanks its doing correctly now, i have problem remembering things what i did before getting older :-(
<IamTrying> I did not put it in APX mode, therefore failed.
<VarmVaffel> is there any way to apt-get install mtd-utils so that the binaries don't get saved in /usr/sbin
<VarmVaffel> so I don't have to be sudo to run them
<infinity> VarmVaffel: Where they live on the filesystem doesn't define who can usefully run them.
<VarmVaffel> yeah I found out
<infinity> VarmVaffel: You could copy the binaries to your home directory, or execute them as a regular user from /usr/sbin/ and they'd likely still be just as useless, cause they require root to do anything.
<VarmVaffel> no they worked without root
<VarmVaffel> thanks for the tips though
<infinity> Ahh, if they really do work without root, you might want to file a Debian bug (or an Ubuntu bug, if it's an Ubuntu-specific package) pointing out that the binaries shouldn't be in sbin.
<infinity> sbin is generally for stuff that really needs root to be useful.
<VarmVaffel> hm yeah ok sure
<VarmVaffel> it was in the standard mtd-utils package
<VarmVaffel> ok it seems like way too much trouble for me with registering an account and reading the guidelines for reporting a bug like this
<VarmVaffel> someone else will have to do it :P
<mjrosenb> js.bad:  ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x31dcd167f7d3c1741274062f1201a623544788e9, not stripped
<mjrosenb> should that be a valid executable on a pandaboard running ubuntu-12.04.1?
<VarmVaffel> seems like it
<mjrosenb> VarmVaffel: well, the kernel does not seem to like it
<mjrosenb> this was built on my debian machine using a cross compiler.
<mjrosenb> building on the board seems to work
<VarmVaffel> what cross compiler
<mjrosenb> (but takes several orders of magnitude longer)
<VarmVaffel> arm-linux-gnueabi?
<mjrosenb> emdebian
<mjrosenb> yes.
<VarmVaffel> and you specified the target arcH?
<VarmVaffel> or board or whatnot
<mjrosenb> -march=armv7-a
<VarmVaffel> then I'm really not sure, never cross compield anything for that particular board before
<VarmVaffel> though I do have it in my drawer
<mjrosenb> ok, it works on my tegra2, which is running 2.6.38.3+ from ubuntu-11.04
<mjrosenb> is it possible that the pandaboard is using -hf, but the tegra isn't?
<mjrosenb> file output does not seem to mention -hf versus softfp
<infinity> File doesn't.
<infinity> You want "readelf -A /path/to/binary"
<infinity> But if you installed from Ubuntu 12.04 images, they're armhf, yes.
<infinity> And your binary is likely armel.
<mjrosenb> so i'll need to get a toolchain that outputs -hf?
<mjrosenb> hrmm, this is non-ideal, since i'm pretty sure android runs -el not -hf
<mjrosenb> infinity: what should be in the output of readelf -A?
<mjrosenb>   Tag_FP_arch: VFPv3-D16
<mjrosenb> would be my guess?
<mjrosenb> or   Tag_ABI_HardFP_use: SP and DP
<mjrosenb> but either way, ew.
#ubuntu-arm 2013-09-23
<AmEv> Hi again.
<Nothing_Much> How do I install Mali 400 graphics drivers on Ubuntu 13.10 armel?
<AmEv> Hey again NM!
<Nothing_Much> Hey AmEv
<Nothing_Much> I need to figure out what these Mali 400 graphics do
<Nothing_Much> Or rather how to install the drivers themselves!
<Nothing_Much> Anybody?
<Nothing_Much> Hm.
<Nothing_Much> Uh
<Nothing_Much> Can I get a status on XMir on Arm?
<AmEv> Try taking a look at http://www.cnx-software.com/2013/02/19/ubuntu-linaro-12-11-with-2d3d-mali-400-gpu-acceleration-on-odroid-x-development-board/
<Vanfanel> Hi there
<Vanfanel> I'm changing current kernel by a custom kernel I've compiled
<Vanfanel> but I get a Kernel Panic because "init not found"
<Vanfanel> Any help is appreciated, thanks
<Vanfanel> I've /etc/init
<Vanfanel> but there's no /sbin/init
<Vanfanel> because I WAS using initrd before
<Vanfanel> So, is /sbin/init on the initrd image??
<infinity> Vanfanel: You're probably failing to specify the root filesystem to mount, which makes it pretty hard to find /sbin/init (which should be on your root).
<Vanfanel> No, it's well specified. It is mounting the rootfs
<Vanfanel> The Panic comes later
<Vanfanel> as it can't find /sbin/init
<Vanfanel> In fact, there's no /sbin/init
<Vanfanel> infinity: is /sbin/init on the initrd by default on ubuntu-arm?
<Nothing_Much> Is Unity available as a package for Armel?
<Nothing_Much> Hello?
#ubuntu-arm 2013-09-24
<Vanfanel> hi there,
<Vanfanel> after adding ppa:tiomap-dev/release repository on Ubuntu 12.04, I wanted to install kernel package: linux-image-3.5.0-223-omap4
<Vanfanel> however, running update & upgrade will only install OMAP4 kernel 3.4
<Vanfanel> do you know what's the problem, please?
<ndec> Vanfanel: where is this kernel supposed to come from?
<Vanfanel> The one I want to install? From this PPA: https://launchpad.net/ubuntu/+source/linux-ti-omap4
<ndec> the 12.04 TI PPA only has 3.4, not 3.5
<Vanfanel> but in that page it says it's supported in 12.04, or am I reading/interpreting it wrong?
<ndec> 12.04 is 'precise'
<ndec> i don't see 3.5 mentioned as supported in 12.04.
<ndec> 12.04 'official' kernel is 3.2, and the TI PPA comes with 3.4
<Vanfanel> ndec: sorry to insist but, what does this line mean then??
<Vanfanel> 3.5.0-233.49 proposed (main) 2013-09-16
<Vanfanel> It's under The Quantal Quetzal
<Vanfanel> here: https://launchpad.net/ubuntu/+source/linux-ti-omap4
<Vanfanel> My understanding on that line is that 3.5 IS supported on QQ
<Vanfanel> Obviously I'm wring
<ndec> QQ is 12.04
<Vanfanel> wrong
<ndec> QQ is 12.10, i meant
<Vanfanel> ahh!
<ndec> ;-)
<Vanfanel> Precisse Pangolin is 12.04 then...
<Vanfanel> I see
<Vanfanel> haha, now it's clear :D
<Vanfanel> Let me add a last question
<Vanfanel> Let's see I have that page: https://launchpad.net/ubuntu/+source/linux-ti-omap4
<Vanfanel> how could I add that PPA to 13.04, for example?
<ndec> this page is not a PPA
<Vanfanel> would it be the same? ie: sudo add-apt-repository ppa:tiomap-dev/release
<ndec> this web page is the 'official' archive content
<Vanfanel> but that page is.. ehmm..  info about a PPA, right?
<ndec> no. it's info about a specific package from the ubuntu archive
<Vanfanel> ok
<Vanfanel> well, ppa:tiomap-dev/release IS a PPA, then
<Vanfanel> so I should be able to do: sudo add-apt-repository ppa:tiomap-dev/release
<Vanfanel> in 13.04 too
<Vanfanel> right?
<ogra_> no
<ogra_> there are no packages for 13.04 in the PPA
<ogra_> would be pointless to add it
<Vanfanel> but OMAP4 special packages ARE installable in desktop 13.04, as if the PPA would come already installed
<ogra_> in the ubuntu desktop images all latest packages for GLES support are preinstalled
<Vanfanel> so.. where do these packages come from in 13.04?
<ogra_> from the archive
<Vanfanel> they can't be "retrieved" from a repository in 13.04 then?
<ogra_> from the ubuntu archive
<ogra_> but they are already installed if yoou use the desktop image, there is nothing to add
<Vanfanel> ogra_: you mean from the official Ubuntu repositories, don't you?
<ogra_> (we dont have codecs for any later release than 12.10)
<ogra_> yes
<ogra_> the PPA only offers yoou codecs fro video playback that only work in 12.10
<ogra_> there is nothing else in that PPA anymore afaik
<Vanfanel> ogra_: I am using 12.04 "core". I got to install from PPA every needed OMAP4 package (kernel, EGL/GLES/libgbm)
<Vanfanel> and tried 13.04 Â·desktop"
<ogra_> ugh
<ogra_> dont use core
<ogra_> it is not for being used, it is for image builders
<Vanfanel> you told me so, ogra_ .. and believe me, I tried the desktop option
<Vanfanel> but it's SO slow it's unusable
<ogra_> (if you want to design an image for a car manufacturer for example)
<Vanfanel> totally utterly unusable
<Vanfanel> And CORE is fast and light
<Vanfanel> I don't need Xorg stuff at all
<ogra_> sure, then go ahead if you feel like
<ogra_> why do you fiddle with the PPA then
<Vanfanel> so building from core is way easier for me...
<ogra_> if you dont need graphical stuff
<Vanfanel> Because I need EGL/GLES on KMS
<Vanfanel> not X
<Vanfanel> I do need graphics, but not X
<ogra_> yes, then you want the pvr driver from the ubuntu archive
<ogra_> *dont* use the PPA
<Vanfanel> I already have everything working on 12.04 core
<Vanfanel> ah
<Vanfanel> ok,ok
<Vanfanel> so, in 13.04, I just don't need to add the PPA!
<Vanfanel> :D
<Vanfanel> I just need to install the OMAP4 stuff from the default Ubuntu repos, right??
<Vanfanel> on 13.04, that's it
<ndec> Vanfanel: ogra_: right, iirc, we released the PVR drivers for 13.04 and they were uploaded in the archive. i forgot about that...
<ndec> i don't remember if what we released at that time had a working EGL/KMS though.
<ndec> also, that wouldn't get you any Gstreamer codec stuff.
<ogra_> ndec, i dont think we changed anything for 13.04
<Vanfanel> I don't need any gstreamer stuff, don't worry
<ogra_> i know Laney and mlankhorst took quite some effort to keep the quantal stack actually
<Vanfanel> it's for an "embedded" project that uses GLES/EGL/KMS only
<ndec> ogra_: still, we don't know what the status of EGL/KMS (e.g. PVR without X11) is with that is in the archive. we might have updaded our drivers in the PPA after we released that to you.
<Vanfanel> ndec: I would need updated drivers as some libgbm functions this project uses aren't implemented in the libdrm in 12.04
<Vanfanel> ndec: so I could use the latest pvr libgbm if available..
<ndec> well, the most 'up-to-date' version would be in the 12.04 PPA.
<ndec> but i am not sure if that would work with 13.04 or not.
<Vanfanel> particularly, this function is unimplemented: gbm_surface_has_free_buffers()
<ndec> for sure it wouldn't work with 13.04 if you were using X11 (X11 ABI changed), but for X-less, i don't know
<Vanfanel> X-less only. But if I won't get any new version in 13.04, I'll stay with 12.04 I guess
<ndec> well, TI has supported 12.04 until March/April this year. so that's your best bet.
<ndec> there has never been any official support on 13.04 or beyond. we only made one code drop to canonical for the PVR drivers to be included in 13.04
<Vanfanel> I feeld sad for the Pandaboard, it's such a great product :(
<ndec> Vanfanel: indeed... most people from TI found new jobs... only panda was left alone ;-)
<Vanfanel> ndec: how hard is it for the PVR on the Panda to get FOSS drivers? For x-less EGL/GLES/KMS stuff without TI involvement
<Vanfanel> no binaries, in the same manner as Intel chipsets get
<ndec> well, i would say that if the scale is 1 to 10 (from trivial to complex), i would say 100 ;-)
<ndec> you realize that you are asking for reverse engineering the PVR GPU, right?
<Vanfanel> ndec: well, I was thinking about some ex-IT guy doing it by knowing the chip's inners
<ndec> hehe... i wonder who you might be thinking about ;-)
<Vanfanel> but according to robclark, you're under DNA
<Vanfanel> you / him
<ndec> yeah, i believe so. that would be very complex anyways to write from scratch., very complex.
<Vanfanel> well, I value a good opinion, so I'm really thankful for your effort in clearing this out for me :)
<ndec> np.
<Vanfanel> hi there,
<Vanfanel> on an OMAP dev board
<Vanfanel> is it possible to boot using omapfb instead of omapdrm using TI's kernel?
<Vanfanel> it boots, by default, with omapdrm
<Vanfanel> and I need omapfb's specific features
<Vanfanel> ok... let's see
<Vanfanel> do you know where can I find the sources for linux-image-3.4.0-1490-omap4 ?
<Vanfanel> how can I install these sources or where is the git repo to get them?
<AmEv> Hey again.
<AmEv> Same question as always: Getting Ubuntu on the Toshiba Thrive.
#ubuntu-arm 2013-09-26
<coolmouse> Waiting for root device /dev/mmcblk0p2...
<coolmouse> why ï¼
#ubuntu-arm 2013-09-28
<eldre> hi, comming for/from ecafe notebook forum
#ubuntu-arm 2013-09-29
<jj1234> anyone have success running 12.04 on a pandaboard ES Rev B3
<jj1234> ?
<axisys> any one installed ubuntu as native on thrive ?
#ubuntu-arm 2014-09-22
<ramsudharsan> Anyone here?
<sudhir__> like to build ubuntu sourc code from scratch,
<sudhir__> could any body provide the link for source code & build guide for the same
<ogra_> sudhir__, which package do you want to build ?
<sudhir__> want to build total ubuntu source code.
<ogra_> sudhir__, then you need to learn hos package buildds work, how dependencies are resolved an a lot of other bits ... read up about that first ... all source code is in source packages on archive.ubuntu.com
<sudhir__> thanks for reply, or could u provide me some idea on, how ubuntu generate daily build or compile for ARM(like OMAP)?
<ogra_> ubuntu daily images are created from binary packages from ports.ubuntu.com
#ubuntu-arm 2014-09-27
<Valduare> hi guys
<Valduare> I have an mk808   well quite a few of them actually
<Valduare> anyone else in here with the mk devices?
#ubuntu-arm 2014-09-28
<Valduare> any one with a cubox-i
<Valduare> morning guys
<Umeaboy> Hi!
<Umeaboy> Who can help me get an updated version of the Ubuntu rootfs tarball to mer? It seems to be missing a dir when you enter the Mer SDK.
<Umeaboy> https://bugs.nemomobile.org/show_bug.cgi?id=770
<ubot2> bugs.nemomobile.org bug 770 in Hybris-ing "Directory /var/run/dbus is missing in SDK root" [Enhancement,New]
#ubuntu-arm 2015-09-21
<flexiondotorg> ogra_, Can you point me at the source for the linux-rpi2 please? I'd like to check the required kernel option for GPIO access are enabled.
<ogra_> flexiondotorg, i'd grab the source package from the queue ... but GPIO is enabled if you use the right bootloader setup
<ogra_> there is surely a tree, but thats kernel team area
<ogra_> GPIO, I2C and PWM are all controlled though bootloader and devicetree overlays
<ogra_> i know paolo made some effort to make sure everything kernel side is enabled for either of the three above
<flexiondotorg> ogra_, http://stackoverflow.com/questions/30442719/getting-segmentation-fault-when-using-rpi-gpio-setup-on-raspberry-pi-2
<flexiondotorg> Seen the comment about CONFIG_STRICT_DEVMEM set true
<ogra_> yeah, seen the comment below that ?
<ogra_> :)
<ogra_> looks like the OP simply used the wrong devicetree
<ogra_> (or none)
<flexiondotorg> :-)
<zirpu> anyone have ubuntu installed on an hp chromebook 14, tegra armv7?
#ubuntu-arm 2015-09-22
<flexiondotorg> ogra_, Do you know if the rpi2 kernel supports the new Raspberry Pi touch screen?
<ogra_> nope, i dont
<ogra_> you'll have to try :)
<ogra_> in snappy we're not at a point to run graphical stuff yet, so i dont think anyone has tested that (given the kernel is very specifically built for snappy)
<flexiondotorg> ogra_, So does the rpi2 kernel support GPIO?
<ogra_> it should, but you will likely need to load the right devicetree overlay in the bootloader
<ogra_> having devices enabled in the kernel doesnt mean they are initialized in the devicetree world
<Osirus126> hello all
<Osirus126> i am having an issue with apt-get update in ubunto Mate for Raspberry Pi
<Osirus126> http://paste.ubuntu.com/12522363/
<k1l_> you could try to rename the named udev rule (to 69-wacom.rules.backup) and see if it works afterwards
<Osirus126> how would i so that? noob here
<k1l_> sudo mv /lib/udev/rules.d/69-wacom.rules /lib/udev/rules.d/69-wacom.rules.backup
<k1l_> might be this bug: https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/1392887
<Osirus126> i dont think i would even need that package on a raspberry pi
<Osirus126> one sec and i will try the fix u gave me
<Osirus126> now i am getting another error im going to reboot and try again one second brb
<Osirus126> bill@RPi-UbuntuMATE:~$ sudo apt-get upgrade
<Osirus126> E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
<Osirus126> E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
<infinity> Osirus126: That means you're running apt/dpkg on another console.
<Osirus126> i dont have any other terminals open
<Osirus126> k1l_, check this out. this popped up when i restarted
<Osirus126> https://bugs.launchpad.net/y-ppa-manager/+bug/1464440
<Osirus126> can someone please help me with this?
<infinity> Osirus126: Just "rm -r /lib/udev/rules.d/69-wacom.rules && apt-get install xserver-xorg-input-wacom"
<infinity> Osirus126: It should be fixed in the newer version.
<infinity> (Not sure why the upgrade is exploding, we can look at that, but the weird directory is gone in the new version)
<Osirus126> so this should fix it?
<Osirus126> what do you mean the wierd directory is gone?
<infinity> Osirus126: I mean that shouldn't have been a directory, it was meant to be a file. :P
<infinity> But the older version of the package had a bug.  *shrug*
<Osirus126> i still got error
<Osirus126> i used that command u gave and still got error
<Osirus126> one sec
<Osirus126> maybe it worked
<Osirus126> no it didnt work
<Osirus126> what would be the command to pastebin the output?
<Osirus126> sudo apt-get upgrade | pastebinit
<Osirus126> ?
<zirpu> anyone running ubuntu-arm on an HP chromebook 14 tegra?
<Osirus126> i dont need that package installed. i wouldnt use it on the raspberry pi. maybe we could just stop it from installing?
<Osirus126> infinity, would that be an option?
<Osirus126> infinity, http://paste.ubuntu.com/12523516/
<infinity> Osirus126: Is your /lib on a different parititon from / ?
<infinity> Osirus126: What's going on in your case looks more fundamentally broken than just the wacom driver being a bit sad.
<Osirus126> possibly
<Osirus126> i am using a bootloader called berryboot
<Osirus126> so the /lib might be on another partition
<Osirus126> yes. my udev folder is in another partition
<infinity> Osirus126: Right, that's not a remotely supportable configuration.  /lib, /bin, /sbin, /etc are expected to be on the root partition.
<Osirus126> ok so if i was to just install ubuntu mate without using berryboot
<Osirus126> it would most likely work?
<Osirus126> like when i go to filesystem and go to lib
<Osirus126> there is no udev folder
<k1l_> Osirus126: there should be a working iso for ubuntu mate and the rpi2.
<Osirus126> yes there is. im sure
<Osirus126> i was using berryboot so i can have multiple os on the same sdcard
<Osirus126> but i will just install using the iso instead and i will let you kno if it works
<Osirus126> infinity, i just reinstalled the image file for ubuntu mate
<Osirus126> infinity, i am updating now. i will let you know if all goes ok
<Osirus126> infinity, i think we figured it out tho. thankyou
<Osirus126> infinity, It worked! thanks alot
#ubuntu-arm 2015-09-23
<flexiondotorg> ogra_, What is the status of linux-raspi2?
<flexiondotorg>  linux-raspi2 | 4.2.0-1008.10 | wily-proposed/universe | source
<flexiondotorg>  linux-raspi2 | 4.2.0.1008.9  | wily-proposed/universe | armhf
<flexiondotorg> Will it be promoted to the release pocket before beta 2?
<ogra_> flexiondotorg, see backlog in #ubuntu-release :)
<flexiondotorg> ogra_, What does that ^^^^ mean to a layman like me? :-)
<ogra_> <ogra_> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ... "linux-raspi2-tools-4.2.0-1008/armhf unsatisfiable Depends: linux-raspi2-tools-common "
<ogra_> <ogra_> we probably want to drop the tools :)
<ogra_> <rtg> hmm
<ogra_> <ogra_> i doubt anyone in snappy will use them
<ogra_> <ogra_> (and i'm not sure how well suited the kernel will be for non-snappy setups)
<ogra_> <rtg> ogra_, yup, will do.
<infinity> ogra_: Eh.  How does one make a snappy-specific kernel, and why would we do such a thing?
<ogra_> infinity, it might have config options that arent desired in "normal" systems
<infinity> ogra_: Like?
<ogra_> no idea, i didnt make the config :P
<infinity> ogra_: We're using the x86 generic kernel for x86 snappy, so that sounds like a BS argument.
<ogra_> just saying i'm not sure it is suposed to be re-used outside of the snappy scope it was developed for
<ogra_> else we'd have used -generic with a RPi specific DT
<infinity> ogra_: And most of the components on snappy weren't "meant to be used outside the classic server scope they were designed for", good thing no one made that arbitrary restriction.
<infinity> ogra_: No, we couldn't use -generic because it's missing a ton of drivers/patches to actually work on rpi2. :P
<ogra_> ah
<infinity> ogra_: This kernel is about enablement, not some snappy-only love-in.
<ogra_> thats not how i understood it, but then it is fine indee
<ogra_> d
<ogra_> (i highly doubt you will make any graphical stuff work on it as is ... but indeed i might be wrong)
<infinity> ogra_: I mean having a separate source package is about enablement.  Yes, the driving force behind supporting the rpi2 at all is snappy, but it's ridiculous to limit it to just one use-case.
<ogra_> (well, perhaps via the fbdev xserver if that still exists )
<infinity> ogra_: Like if I told you that I'm building packageX with options that make it unsuitable for snappy because screw you, it's a server package. :P
<ogra_> well, it was created for cloud and embedded use for now ... nobody looked at making kms graphical stuff work or anything so re-using it for desktop enabled might or might not work
<ogra_> thats all i'm sying
<ogra_> *enablement
<infinity> ogra_: Sure, did I say anything about graphics? :P
<infinity> ogra_: Dropping tools and debug symbols made it unsuitable for anyone doing any debugging on a deb-based system (or, alternately, for anyone who wants to sort out how to deb2snap those bits to debug on a snappy system, if you want to pretend snappy is the whole world).
<ogra_> the config in use was created based on requested snappy requirements ... so nobody can guarantee anything outside of that scope
<ogra_> i dont say that
<infinity> ogra_: Either way.  The argument is silly.  If we're using generic kernels elsewhere, this one should have a config review and be a generic kernel, not a unique snowflake.
<ogra_> i just say it was driven by snappy and nobody looked into making it work in any other context yet
<infinity> If something is "necessary for snappy", it's necessary on all platforms, not just rpi.
<infinity> ogra_: I'm slightly amused about "other contexts".  Other than how it boots, snappy and regular old ubuntu server are effectively identical. :P
<infinity> (Well, how it installs, boots, and manages packages, but the userspace is the same)
<ogra_> not sure ...
<ogra_> i.e. the RPi uses a very specific bootloader setup ...
<ogra_> you cant just use DTs from uboot
<infinity> That's not snappy-specific.
<infinity> That's rpi2 specific.
<ogra_> no. thats RPi specific
<infinity> Yeah.
<infinity> So, again.  There's nothing snappy about this kernel.
<infinity> Anyhow.  I'm done ranting.
<ogra_> ok :)
<infinity> And I yelled at Tim for listening to you about dropping half his package. :P
<ogra_> well, we used to drop the tools in the past from the arm kernels
<infinity> (And, for the record, there are people, including our own kernel engineers, running non-snappy Ubuntu on rpi2, cause snappy itself is a crap development/debugging environment)
<infinity> ogra_: No we didn't.
<infinity> ogra_: Unless you mean some distant past 6 years ago.
<ogra_> we definitely did
<ogra_> for at least 10 kernels i had to work with in the last 5 years
<infinity> ogra_: ti-omap4 and armadaxp and keystone (all the ones we still support) have tools.
<infinity> ogra_: The linaro kernels didn't, but they were crap.
<ogra_> since when does omap have tools ?
<infinity> Since always.
<ogra_> i know we had to explicitly rip them out for years
<ogra_> that must have happened after 12.04
<infinity> 12.04 was a long time ago now. :P
<infinity> Time to get with the times, grandpa. ;)
<ogra_> 12.04 was when we dropped tthe panda :)
 * ogra_ shakes his cane
<ogra_> well, post 12.04 was
#ubuntu-arm 2015-09-24
<flexiondotorg> ogra_, Does the linux-raspi2 kernel also provide the bootloader?
<ogra_> nope
<flexiondotorg> OK, where does Snappy get that from then?
<ogra_> from the oem snap
<ogra_> (soon to be renamed to gadget snap)
<flexiondotorg> Right, so this is a snap tool that provides the required device specific "stuff"?
<ogra_> no, its a snap developer who does :)
<flexiondotorg> So, I know practically nothing about Snappy.
<ogra_> there is no tool beyond "snappy build" to finally assemble the snap from a tree of binaries
<flexiondotorg> I'm not doing Snappy for Ubuntu MATE (yet).
<flexiondotorg> I know how to put the boot loader etc in the right places and have debs for that.
<ogra_> yeah, you probably dont want to yet
<flexiondotorg> But I'm interested to understand the mechanis for this with snappy.
<ogra_> for snappy you need to try to think out of debs and closer to upstream
<flexiondotorg> ogra_, Yeah I've been told to not adopt snappy just yet.
<flexiondotorg> Before :-)
<flexiondotorg> ogra_, I understand the concept of snappy, just not how a snappy OS if created.
<flexiondotorg> but, I've got my answer.
<ogra_> a snap is just a collection of binaries and glue between them, how these binaries are produced is up to the person making the snap
<flexiondotorg> I can used the linux-raspi2 kernel (when available) and I'll have to provide the bootloader, firmware and GPU drivers myself.
<ogra_> right
<flexiondotorg> ogra_, So the snap binaries.
<flexiondotorg> This is a prebuilt OS for different architectures?
<ogra_> we might focus on getting the free graphics driver to work
<flexiondotorg> A generic rootfs, if you will?
<ogra_> so this might end up in the archive proper
<flexiondotorg> ogra_, OK cool.
<ogra_> the snappy OS is similar to the phone today ...
<flexiondotorg> ogra_, The is also the fbturbo driver that is 2D accelerated for Pi2.
<flexiondotorg> ogra_, Understood.
<ogra_> you have a generic rootfs and a device tarball that carries all device specific bits
<flexiondotorg> And can I create my own "device tarball"?
<ogra_> the oem snp from above describes that combo and ships everything necessary to boot
<flexiondotorg> ogra_, BTW, thanks for answering all these questions.
<ogra_> np :)
<flexiondotorg> ogra_, OK, thanks.
<flexiondotorg> After 15.10 I think I'm going to spend to first couple of week into 16.04 playing with snappy.
<ogra_> the oem snap can also describe what app snaps you have preinstalled ... and even potentially ship default confis for them
<flexiondotorg> ogra_, Am I right that snappy is not suited for graphical applications right now?
<ogra_> so it is very easy to build an appliance for example
<ogra_> there is some Mir demo snap for amd64 i think, so it is "a little" suited :)
<flexiondotorg> OK
<ogra_> but far from ready for general use
<flexiondotorg> Xmir?
<ogra_> not sure if it includes Xmir
<flexiondotorg> OK
<flexiondotorg> Finally, app snaps.
<flexiondotorg> Are these discrete apps that can have inter apps dependencies or are they everything you need for a full stack app?
<flexiondotorg> More precisely.
<ogra_> well, imagine them as "metapackage on steroids"
<ogra_> or "project packages"
<flexiondotorg> If I wanted to make a snap of Discourse, would everything required by Discourse be in a single app snap?
<flexiondotorg> Like I do it with Docker now.
<ogra_> i.e. i'm currently packaging a mailserver snap ... that consistes of dovecot, postfix, spamassasin and the bits needed to make them work together
<flexiondotorg> Ok, understood.
<flexiondotorg> So, in the future, if I wanted to make Snappy MATE the whole desktop and all compoents applications would be a single app snap?
<ogra_> yeah ... plus application snaps
<flexiondotorg> So, MATE desktop would be one snap. Firefox another. LibreOffice another and so on?
<ogra_> i.e the whole basic desktop would be one single one ... and then you have a libreoffice and a firefox snap on top
<ogra_> heh
<flexiondotorg> Exactly.
<flexiondotorg> Cool.
<ogra_> *snap*
<ogra_> :)
<flexiondotorg> :-D
<flexiondotorg> In 10 minutes you taught me everything I needed to know.
<ogra_> haha
<ogra_> there is also #snappy btw :)
<flexiondotorg> OOh.
<flexiondotorg> And joined. Thanks.
<ogra_> and very newly we have snapcraft ... a tool that makes building snaps easy enough my mom coould do it ;)
<ogra_> well, probably not my mom :)
<flexiondotorg> For building app snaps?
<ogra_> but yu dont need big skills with it
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/ircproxy/files
<flexiondotorg> ogra_, Reading that now. You should use ZNC ;-)
<ogra_> all you need is the snapcraft.yaml ... the rest is fully automatic (the other bits there are just glue)
<flexiondotorg> Coolness.
<ogra_> yo go into the dir with the snapcraft.yaml ... call snapcraft and out comes a snap
<flexiondotorg> stage-packages being debs?
<ogra_> and if you upload your branch to LP there is a single button "build snap" that does the same and even uploads it to the store for you
<ogra_> right
<ogra_> but they could also be a github branch
<flexiondotorg> Oh man. That is brilliant.
<ogra_> that would then get automatically built
<ogra_> or some other upstream centric thing ...
<flexiondotorg> Is that LP button in there now or coming?
<ogra_> its in there right now
<flexiondotorg> OK, getting distracted from my 15.10 beta 2 testing now.
<flexiondotorg> So want to play with that.
<ogra_> haha
<flexiondotorg> Must resist.
<flexiondotorg> Thank you.
<ogra_> yeah, finish your beta :)
<flexiondotorg> That has totally sold me on the idea.
<flexiondotorg> I'll be playing with Snappy after I've got 15.10 out the door.
<flexiondotorg> Many thanks.
<ogra_> if you have questions (you surely will) ask in #snappy :)
<flexiondotorg> Will do.
#ubuntu-arm 2016-09-26
<pz91> hello, how can I add device to device tree without rebuilding kernel? I have .dtd file with dev info.
#ubuntu-arm 2016-09-30
<ali1234> is there a tool for setting the snapdragon fuses? other than the proprietary windows ones :)
<ali1234> also, is there a tool to read the hidden boot partitions on the emmc?
<Kinli> join #arm-linux
<Kinli> oops
<Kinli> When I'm calling a system call with SVC 0, R7 contains the number of the system call from arch/arm/kernel/calls.S?
#ubuntu-arm 2017-09-25
<alex1s> Hi all, there is an issue with the firefox 55.0.2 package, it crash when launched on all armhf ubuntu plateform I have tested, I have to downgrade to version 45.0.2 ?
<alex1s> Here is the crash report https://pastebin.com/jnXwWGJ2
#ubuntu-arm 2017-09-28
<manjo> meet @6:30 in the lobby for team dinner
