#ubuntu-arm 2009-08-31
<siji> Hi all i had created ubuntu rootfs as per ogra's tutorial
<siji> and boot frm it using qemu
<siji> and inside qemu i added some packages on the root system like gtk etc..
<siji> now how can i make it again rootfs frm there
 * ogra-babbage waves
<ogra-babbage> ogra@babbage2:~$ sudo hdparm -t /dev/sda1
<ogra-babbage> /dev/sda1:
<ogra-babbage>  Timing buffered disk reads:   64 MB in  3.02 seconds =  21.22 MB/sec
<ogra-babbage> hmm, it feels a lot slower
#ubuntu-arm 2009-09-01
<ali1234> does console-kit-daemon really need to use all spare cpu time or is it a bug?
<lool> ali1234: it's a bug
<lool> ali1234: What environment do you see this in?
<ali1234> lool: i'm running on omap850 after using the "root from scratch" script with --seed=lxde,gdm
<lool> ali1234: Could it be an option missing from your kernel?
<ali1234> yes, it certainly could. but which one?
<lool> ali1234: I would strace consolekit to see whether it's failing a syscall or something like that
<lool> ogra: Did you ever see 100% used with CK?
<lool> I didnt ever see this
<ogra> nope
<ogra> but i remember the desktop team had a bug about it early in jaunty ... though that was fixed for release
<ogra> CK did spawn threads endlessly iirc
<ali1234> i saw that bug on launch pad, it seems to be a memory leak issue with lots of ssh connections. i only have one
<ali1234> strace just says: restart_syscall(<... resuming interrupted call ...>
<ali1234> then nothing
<ogra> hmm, why dont we have a dove image today
<ali1234> it almost is a kernel issue since i'm using 2.6.25 and no particular config
<ali1234> *almost certainly
<ogra> lool, Couldn't open .flint/dbw/postlist.baseA: Too many open files
<ogra> Couldn't open .flint/dbw/postlist.baseB: Too many open files
<ogra> )
<ogra> do you think it's worth trying to giv that back ?
<ogra> (thats xapian-core)
<ogra> seems like a buildd issue
<lool> hmm
<lool> Any other build like this?
<ogra> nope
<ogra> xapian seems to hammer the disk during its test phase
<lool> I guess you could give it back
<ogra> we have two idling buildds, i'll just try
<lool> ogra: livefs failed to build
<lool> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu-dove/latest/livecd-20090901-armel.out
<lool>   empathy: Depends: libmissioncontrol-client0 (>= 4.37) but it is not installable
<ogra> ah, yeah, empathy
<lool> evolution and others
<lool>   evolution: Depends: evolution-common (= 2.27.90-0ubuntu2) but it is not going to be installed
<ogra> i just gave back evo, it always needs handholing
<ogra> seb never waqits until the "all" packages are published
<ogra> hmm, xapian has the same issue on ia64
<ogra> and on sparc
<ogra> lool, i dont get why dove wouldnt use an older livefs as all other arches do though
 * ogra pbuilds xapian-core locally
<lool> Oh that's unrelated, I actually broke the build but I fixed it now
<lool> Well I think, I'm test building
<lool> poumpoudoum
<ogra> poumpoudoum ?
<lool> lalala if you wish
<lool> ok it built
<lool> hmm that's bad
<lool> /home/lool/cdimage/debian-cd/tools/pi-makelist-vfat: Couldn't list any drive
<ogra> oh
<ogra> i thought you were talking about xapian and wondered whn you secretly pushed that to the buildds :)
<ogra> ETOOMANYTOPICSATONCE
<lool> Oh
<lool> We never actually cared to support partition=1 in pi-makelist-vfat
<lool> only no partition or part 2
<ogra> which didnt fail since we never used partition 1 yet
<lool> Hmm oddly it doesnt work with partition=1 either
<lool> Ok found another bug in that script which went unnoticed
<lool> Oh no it was just local to my edit, some typo during copy-paste caused a lowercase or something
<lool> and it worked, cool
<lool> all deployed, just waiting to confirm I can kick a rebuild
<lool> Sure enough http://cdimage.ubuntu.com/ports/daily-live/20090831/karmic-desktop-armel+dove.list was empty
<rabeeh> lool: which machine are you using for that build?
<rabeeh> lool: are dove machines already part of the buildd cloud?
<ogra> rabeeh, nope
<lool> rabeeh: No, imx51 based
<ogra> we hope to add dove soon though
<lool> rabeeh: I dont think we can get z0 stable enough and we dont have enough yX
<rabeeh> isn't that incremental work? meaning if you have 1 yx then you can add to buildd, and if you have 2 then you can add 2?
<lool> My main worry is silent breakage: it might be ok if a buildd goes completely missing and has to be remote rebooted but it's not ok if it breaks in the middle of a build: it could either cause a subtle breakage to go unnoticed and if it actually fails the build we cant distinguish hardware errors from software ones which we need to fix  :-/
<rabeeh> i mean you can start with what you have, and get more soon.
<ogra> but we dont have a single one we can spare yet
<lool> rabeeh: I think we could start like that, but we have no facility to schedule builds on this or that buildd
<rabeeh> so, what is the yx board allocation o buildd/developer?
<rabeeh> btw - is it possible to set a board remotely part of a buildd?
<rabeeh> for example i have my own y0 board; that is free at nights and weekends; can i set it (behind a firewall) to be part of the buildd cloud?
<rabeeh> (i know; this is intermediate solution until you get the amount of boards you have requested)
<ogra> we have 7 armel buildds atm ... https://launchpad.net/builders
<rabeeh> for example, you can never ssh to the board; but the board can poll and pull build requests from the web
<ogra> and as you can see currently two are idle, one is in maintenance
<ogra> having more doesnt really help, having faster ones will ...
<ogra> which is why we look forward to add doves
<rabeeh> hmm. why?
<ogra> because one package is built on one buildd
<ogra> if you take openoffice it takes about 36h to build
<rabeeh> but they are idle :)
<rabeeh> don't they have queues for karmic builds?
<ogra> having it building in 24h would improve ... having one more buildd wouldnt help speeding it up
<ogra> its not a cluster where adding more power would improve anything for the single build
<ogra> adding more machines just lets the qeue get empty faster
<ogra> butu the queue as you can see is empty most of the time ... it might indeed help at high times where you have tons and tons of uploads
<ogra> the amount of 7 machines is quite ok ... replacing them incrementally with doves will help a lot but we currently need the few doves we have for development and QA of the dove image we build
<rabeeh> which machines you have here are running on discovery 78100?
<rabeeh> i recall canonical had few of those machines for jaunty armv5 armel distro
<rabeeh> my point is can we use armv5+vfp machines for armv6+vfp?
<ogra> right, but after the alpha5 release (thursday) we will default to only build for v6
<ogra> no, you cant use v5 machines for that
<rabeeh> (implementing software instruction abort handlers for the armv6 part)
<ogra> thats why we currently are stuck with imx51 machines
<ogra> how stable would such a software layer be ... how much slowdown would you get through such an additional layer
<rabeeh> well. it's hard to guess; but armv6 has big SIMD addition; which is never used in integer/floating based application
<lool> sorry had an UPS delivery
<rabeeh> it is used in packages like ffmpeg; and might only break if the debian/rules calls some test to use that
<lool> and it's broken so I need to deal with it
<rabeeh> lool: hope it's not Dove :)
<lool> It's not  :)
<ogra> my assumption is that if you develop such a layer to run on v5 buildds you invest a lot of time to make sure its stable enough, do QA on it etc
<ogra> and i bet once you are done the amopunt of y0 we want is available :)
<ogra> so using imx51 until that point serves as well without risking stability
<rabeeh> right. and i'm looking at the instruction set addition; and seems lots of instructions being added
<ogra> right
<rabeeh> will take lots of time to implement those exception handlers
<rabeeh> ogra: what i can promise is that y1 boards will come with 1GB of DDR :)
<ogra> effectively you would end up with something like qemu-arm inbetween the CPU and userspace
<ogra> WOW !
<rabeeh> right
<ogra> that will make a huge improvement !
<ogra> the diskspeed already is a huge improvement on the dove vs imx
<ogra> adding more ram will make the builders fly :)
<rabeeh> personally i think we should have buildd version of dove
<rabeeh> overclocked and even more DDR
<rabeeh> lunch time :) ttysw
<ogra> :)
<lool> rabeeh: It's common for packages to call binaries from others; not frequent but common enough that it needs to work well; for instances all GStreamer apps call the equivalent of gst-inspect on startup which will cause all plugins to be loaded
<lool> Including ffmpeg
<lool> (Now Gst is a special case because it actually traps sigill but still :)
<rabeeh> ogra: back to the original question; is it possible that put my board part of the buildd cloud? (inside a firewall)
<rabeeh> lool: got it.
<ogra> rabeeh, nope, our IS team wouldnt allow that i guess
<tlee> Has karmic's arm build system move to vfp yet?
<ogra> after alpha5 we'll move immediately
<tlee> Thanks Ogra.  How many days (weeks) is that from now?    Also how long you think it would take to rebuild all the packages?
<ogra> alpha5 images will be released on thursday
<ogra> (including a dove live image btw)
<ogra> testing appreciated :)
<ogra> no idea how long it will take to rebuild the whole archive ... i'd guess a week or two
<ogra> lool, any idea ?
<lool> ogra: we moved already
<lool> to vfp
<lool> tlee: we're using v6+vfp at the moment
<ogra> oh !
<lool> We wont rebuild the archive
<ogra> dont we do a complete rebuild anyway during the process ?
<lool> What do you mean?
<tlee> wow.
<ogra> lool, on the std arches we usually do a complete archive rebuild before final
<ogra> https://wiki.ubuntu.com/KarmicReleaseSchedule spt24th
<ogra> *sept
<ogra> and oct 15th
<lool> ogra: That's out of archive
<lool> We dont keep the results
<ogra> oh, i thought we did
<lool> ogra: So did you get like thousands of packages to download on the week before release?   :)
<ogra> why would i if the versions dont change
<lool> ogra: Because the binaries arent identical
<lool> ogra: It would be a terrible idea to have two .debs with different md5 and contents named the same thing and using the same version; we never do that
<ogra> oh, indeed
<lool> And it's also why we wont rebuild the whole archive just for armel
<ogra> yeah, understood
<ogra> thast a bit sad though
<lool> Not too much
<lool> But it's why the lack of buildd was such a big deal
<ogra> indeed
<lool> But given the number of uploads before release it's not that bad
<ogra> true
<ogra> problematic is that we wont see fallout caused by the setting for packages that werent uploaded
<ogra> we'll likely hit the ftbfs'es for these in karmic+1 only
<tlee> Have any of you seen this "BUG: soft lockup - CPU#0 stuck for 61s!"?
<ogra> nope, not on armel yet
<tlee> Google it and it seems to happen a lot of times in kernel.
<ogra> i have seen it on via eden
<ogra> and other thin clients i worked with (geode etc)
<tlee> orga:  turn on nullmailer and see if you can see what I seen on karmic.
<ogra> oh, wait, looking at my dmesg ...
<ogra> http://paste.ubuntu.com/263307/
<tlee> I believe I have 400+ email Q to send out and nullmailer is trying to run every few minutes.  Seems to trigger that erorrs for me.
<ogra> it's currently doing a heavy duty build
<tlee> on Karmic.  Quite offer.
<ogra> NCommander, http://paste.ubuntu.com/263307/
<tlee> On Jaunty, I see the bash has issue.
<ogra> NCommander, watch your dmesg on the dove under load, appears to be a kernel bug
<tlee> On Karmic, seems only the nullmailer.
<ogra> well, i'm building a package here
<ogra> and it seems to have been triggered by bash
<tlee> Do you know any method to help track this bug down?
<ogra> i pinged bjf in #ubuntu-kernel
<bjf> orga, I can *sigh* here just as easily
<ogra> heh
<ogra> note that i use the -201 build still
<bjf> ogra, oh! well that's obviously your problem :-)
<ogra> not sure if 202 or 203 fix it, but i guess tlee runs something newer
<ogra> i cant replace the kernel before webkit isnt finished, i need the log
<ogra> and that might go on for the rest of the nigh ...
<ogra> +t
<bjf> ogra, I'll boot mine up and see what I see
<ogra> i didnt see it before
<ogra> seems to be load related
<tlee> orga: what do you mean by 201, 202, 203?
<ogra> the kernel builds
<ogra> its the ABI version of the packaged kernels we use
<bjf> tlee, you will see the version as 2.6.31-203.8, the 203 is the API versions
<ogra> http://ports.ubuntu.com/pool/main/l/linux-mvl-dove/
<tlee> I am still back in 2.6.30.  I built 2.6.31 last week, have not try it yet.
<ogra> linux-image-2.6.31-203-dove_2.6.31-203.7_armel.deb is the current package
<ogra> (i think there is one pending in the queue though)
<bjf> ogra, yes there is one "in the queue", it has some of the latest mvl changes and we are building zImages instaed of uImages
<ogra> yeah, i saw the thread on the ML
<tlee> Ok, I will try to sync it up tomorrow. Have some demo to do today. Don't want to mess with the demo god for now.
<ogra> heh
<bjf> tlee, I hear that!
<tlee> I am in trouble now.  Lighting is stiking from above..... run ..... :-)
<ogra> haha
<NCommander> ogra, yeah, I've seen that. Thought it was an issue with the old kernel I was using
<NCommander> It didn't reappear since I updated to a 202 kernel, although I haven't been using that as extensively
<NCommander> actually
<ogra> ok, i'll see what 203 does for me then
<NCommander> er
<NCommander> 203
<NCommander> er, 202 or 203
<NCommander> I used to get it trying to spin livecd-rootfs's
<NCommander> then it went away when I updated the kernel
<tlee> There is no uImage in the linux-image-2.6.31-203-dove_2.6.31-203.7_armel.deb.  How do I make the uboot to load vmlinuz?
#ubuntu-arm 2009-09-02
<NCommander> tlee2, you have to use the mkimage command
<NCommander> tlee2, we made that change to make other things in our backend work a bit more sanely :-)
<erikcorry> Anyone awake?
<erikcorry> I tried rootstock.
<erikcorry> It did a whooole lot of work.
<erikcorry> I'm wondering if it made anything.
<erikcorry> No new files in current directory.
<erikcorry> Where should I be looking?
<ogra> there should be files in the current dir
<ogra> what was the commandline you used, which release are you on ?
<erikcorry> I'm running on a Hardy-based x86 host.
<erikcorry> So probably I'm hosed?
<erikcorry> sudo ./rootstock -f name.example.com -l erikcorry -p foobar
<ogra> hardy is to old
<erikcorry> damn
<ogra> you can bootstrap a jaunty chroot (using the jaunty debootstrap) and run rootstock inside there
<erikcorry> OK
<ogra> (well, hardy isnt necessarily to old, but i never tested it on hardy and didnt develop it on hardy so i wouldnt know what issues can come up there)
<erikcorry> When it says I: Switching to Virtual Machine for second stage processing
<erikcorry> I can't see anything.
<erikcorry> Would I be able to see the VM running if I had my X display set up right?
<ogra> nope, it doesnt use graphical output
<ogra> it spawns the VM with a serial terminal and the script interacts through that with the VM
<ogra> might be that hardy's qemu doesnt work for armel
<ogra> we didnt support that arch back then, so i dont know if anyone paid attention to arm stuff
<ogra> though if you say it switches to the VM, did you wait long enough ... it can take quite a while until it moves on
<erikcorry> It's running at 100% CPU so it's doing something.
<erikcorry> I have qemu 0.91
<ogra> how long did you wait yet
<erikcorry>  I waited a long time and it continued.
<ogra> ah
<ogra> yeah, the qemu part is very slow
<erikcorry> Now it's scrolled off the top of the scrollback buffer so I can't see what happened
<ogra> i hope to fix that for karmic
<erikcorry> I'm running it again.
<erikcorry> I'll report what happens.
<erikcorry> Is it just because the qemu ARM emulator is slow?
<ogra> yeah
<erikcorry> I: Unpacking required packages...
<ogra> looks good :)
<ogra> just let it run... make some coffee ... drink it ... take a walk and then look again :)
<lool> ogra: Could you blacklist older dists in rootstock
<lool> ogra: Also could you stop installing ubuntu-minimal by default?  It's pulled by debootstrap in all cases and breaks on Debian
<ogra> rootstock only builds for jaunty and karmic and is only packaged for karmic
<lool> Oh so it refuses a hardy target already ok
<ogra> i cant stop people from pulling from bzr
<lool> We could runtime check for the qemu version if that's the issue
<ogra> -minimal was explicitly added as a no-op ... i didnt take debian into account back when i created rootstock
<ogra> there is apparently no issue, its just the general slowness
<lool> Yeah could you make it "" instead of ubuntu-minimal?
<ogra> indeed
<lool> Cause it's always pulled
<ogra> though it will still break on debian without additional changes i guess
<erikcorry> dpkg: failed to write status record about `libxslt1.1' to `/var/lib/dpkg/status': No space left on device
<ogra> $DIST defaulting to karmic for example (though you can override it)
<ogra> erikcorry, you picked the imagesize wrong
<ogra> take a bigger value
<erikcorry> Yeah, I just let it use the default.
<erikcorry> 1G
<erikcorry> 4G is big enough?
<ogra> future versions will properly compute the size they need based on the package selection
<ogra> what do you install ? a desktop will need 4G, yes
<erikcorry> Thx
<erikcorry> starting it again
<erikcorry> I think I probably ran out of host disk space first time I ran it.
<erikcorry> Target disk space second time.
<ogra> oh, yeah, you will need some space for that on your host :)
<ogra> at least the amount of the imagesize
<ogra> plus whatever comes out of the script at the end as tarball
<ogra> 1.5 times imagesize should be a good measure
<ogra> lool, that will require more than ""
<ogra> ogra@osiris:~/Devel/branches/rootstock-0.1.1$ LANG=C sudo apt-get -y install ""
<ogra> Reading package lists... Done
<ogra> Building dependency tree
<ogra> Reading state information... Done
<ogra> E: Couldn't find package
<lool> You need me to help fix that?  :)
<ogra> nah
<ogra> fixed and pushed
<lool> thanks
<erikcorry> dpkg-preconfigure: unable to re-open stdin:
<erikcorry> It looks like it might be harmless
<erikcorry> OK that didn't work.
<erikcorry> Looks like my old Qemu isn't up to the task, as you predicted.
<erikcorry> Any tips on making a jaunty chroot area with debootstrap?
<erikcorry> https://help.ubuntu.com/community/DebootstrapChroot
<erikcorry> " the debootstrap that is bundled with Hardy cannot prepare a Jaunty chroot."
<erikcorry> Damn
<ogra> its just scripts ... you can pull the jaunty one and just dpkg -i it
<erikcorry> It seemed to build something anyway.
<erikcorry> But when I chroot into it apt-get doesn't work.
<erikcorry> # apt-get install svn
<erikcorry> Reading package lists... Done
<erikcorry> Building dependency tree... Done
<erikcorry> E: Couldn't find package svn
<erikcorry> doh!
<erikcorry> It's called subversion
<erikcorry> Standard debootstrap from jaunty doesn't seem to have a script for karmic.
<ogra> no, for jaunty
<erikcorry> But if I want the latest greatest ARM stuff I have to use karmic, right?
<ogra> if you want the unstable arm stuff you want karmic :)
<erikcorry> For some reason the debootstrap I had on hardy already had that script.
<ogra> indeed that also has the latest and greatest
<erikcorry> Is there any other kind of arm stuff?
<erikcorry> :-)
<ogra> heh
<erikcorry> What's the best way to upgrade one single package?  Just download it as a deb or should I do something to my sources.list file?
<erikcorry> Sorry about all these newbie questions.
<ogra> what package ?
<erikcorry> It's OK.
<erikcorry> I found a newer debootstrap than the one that came with jaunty and installed it.
<erikcorry> Now I have the karmic script.
<ogra> ok
<erikcorry> Enhancement request for rootstock:  If the /usr/share/debootstrap/scripts/karmic file is not there then give a good error message.
<ogra> it does if the debootstrap version isnt right
<erikcorry> Debootstrap was newer than 1.0.10
<erikcorry> Which I think is what it tests for.
<ogra> it looks for something that can build jaunty
<ogra> in karmic it is packaged and the package depends hard on the right version
<erikcorry> But the -d option defaults to karmic
<erikcorry> The standard debootstrap in jaunty is 1.0.12 which can't build karmic.
<erikcorry> The 1.0.13~jaunty1_all version can
<ogra> right, but i dont want to force jaunty users to update debootstrap, they should use -d jaunty
<erikcorry> Whatever -d option they use that should be the one that you check for in /usr/share/debootstrap/scripts/
<erikcorry> At the moment it bombs out with a cryptic error message and leaves the image mounted.
<ogra> thats a bug indeed
<ogra> it should clean up after itself
<ogra> i will make $DIST default to the host distro and make it throw an error if its pre jaunty
<erikcorry> But you do expect that one can build a karmic ARM system on a Jaunty host?
<lool> If you install debootstrap probably
<ogra> sure
<ogra> and thats why the script has a -d option
<ogra> the default for that options is picked wrong though
<erikcorry> I sent you a patch.
<ogra> oh, thanks !
<erikcorry> It's not tested :-/
<erikcorry> It's just to illustrate what I mean.
 * ogra waits for it 
<ogra> essentially it should just be: DIST=$(lsb_release -cs)
<ogra> and probably an error message telling you you cant build for future distros without future debootstrap
<ogra> ah, there it is
<ogra> perfect, that and the lsb_release change together will make it work right
 * ogra adds that to bzr
<ogra> erikcorry, mind if i move that check a bit earlier so it fails before it actually uses diskspace ?
<ogra> committed and pushed
<erikcorry> Sounds fine.
<NCommander> lool, ogra, would you like to look over my flash-kernel changes? (I'm about to do an install with them in place to make sure they work as excepted, but I'd like any input: http://paste.ubuntu.com/263860/)
<zul> hi has anyone seen bug #416313
<ubot4> Launchpad bug 416313 in samba "On samba of ubuntu-arm, large file copy fails " [Undecided,New] https://launchpad.net/bugs/416313
<lool> ogra: You kicked some live builds?
<lool> I mean livefs
<tlee> ogra:  How do I use hte linux-mvl-dove from uboot?
<ogra> NCommander, ^^^
<NCommander> tlee, is your root filesystem ext2 or ext3?
<NCommander> If the answer is no, then you can't load it directly :-/
<tlee> ext3 on sata
<NCommander> Well
<NCommander> That will work :-)
<NCommander> tlee, are you using a separate boot partition or no?
<tlee> yes.
<tlee> I can configure it anyway you like.
 * NCommander thinks he just found a test victim :-)
<tlee> Is there a wiki howto?
<NCommander> tlee, its not fully up to dat eyet, I'm currently working on extending u-boot's boot scripts to automatically scan usb and SATA HDDs for the ubuntu boot.scr file :-)
<tlee> tlee thinks he just been victimized.  :-)
<tlee> I play with boot.scr before.
<NCommander> tlee, we do have working live images, but the installer kinda fubar'ed
<NCommander> tlee, http://people.canonical.com/~mcasadevall/karmic-desktop-armel+dove.img
<NCommander> tlee, download that, stick it on a pendrive, and then you can start the live environment :-)
<tlee> Which uboot do I need to support this scan function?
<NCommander> tlee, the one I haven't written yet ;-)
<tlee> Would the default Y0 uboot work? (Whatever default means...)
<NCommander> tlee, (I'm working off the Marvelll 4.2.3 source drop with a few patches to turn the Hush shell on)
<NCommander> tlee, you need Y0 4.2.3
<NCommander> (check the version string)
<tlee> Will check which one I have now.
<NCommander> but thats just to start the live image, I'll have a new u-boot binary that sits in NAND flash (vs. spi-nor) which handles the scanning
<tlee> NCommander, my uboot is  4.1.7.  Do I get the updated uboot from u?
<tlee> or MVL
<NCommander> tlee, I'm not sure if I can post u-boot binaries or not
<NCommander> but you'll need a newer one :-/
<tlee> Will email u....
<armin76> NCommander: what is a dove board? :)
<ogra> armin76, upcoming hardware
<armin76> rabeeh: i want one :P
<suihkulokki> without knowing what it is? :)
<rjune_> suihkulokki: it's new, therefore it must be cool
<ogra> suihkulokki, be sure you want one too once they are on the market
<NCommander> armin76, wow, your a real ARM diehard :-)
<NCommander> armin76, :-)
<armin76> NCommander: i always like to try new stuff :)
<NCommander> armin76, I should send you my MIPS laptop
<armin76> NCommander: got bored of it? :)
<NCommander> armin76, it doesn't work too well with lenny
<NCommander> and the Xorg I need is still stuck in sid I think
<NCommander> and sid is extra broken recently
#ubuntu-arm 2009-09-03
 * ogra-babbage waves from his test install
 * ogra-babbage twiddles thumbs waiting for the install to finish
 * ogra-babbage reboots his new install
<erikcorry> On http://archive.ubuntu.com/ubuntu/dists/karmic/main/ I see subdirs for intel architectures, but none for ARM.
<erikcorry> Should I be looking somewhere else?
<ogra> ports.ubuntu.com
<erikcorry> thx
<ian_brasil> http://gadgets.boingboing.net/2009/09/02/photo-and-descriptio.html
<ian_brasil> Amazon Kindle 2 com Ubuntu ARM
<lool> Oh
<lool> To open up the Kindle, I used the USB networking debug mode Amazon left hanging around when they first shipped the Kindle 2, a statically linked telnetd and a cross-compiler to bootstrap myself.
<lool> Nice
<ogra> "to bootstrap myself" ... grin
<rabeeh> lool: online?
<lool> rabeeh: Yup
#ubuntu-arm 2009-09-04
<erikcorry> gcc 4.4.1 seems to be generating some screwy code for me.
<erikcorry> Is there a newer release I could try?
<lool> erikcorry: Is this reported?
<lool> erikcorry: 4.4.1 is the latest we have, but we add patches
<erikcorry> I'm trying to reduce it.
<erikcorry> Fails to compile Google V8
<erikcorry> In -O2 mode
<erikcorry> I already added -fno-strict-aliasing
<erikcorry> Gotcha.
<erikcorry> Who should I mail the reduced test case to?
<lool> erikcorry: Upstream?  :-)
<erikcorry> Or should I just file a bug on gcc's site?
<lool> erikcorry: I'd file a bug against gcc-4.4 upstream
<lool> Yeah
<erikcorry> It only happens with -O3
<lool> erikcorry: You could find out which subopt breaks it
<lool> erikcorry: gcc -c -Q -Os --help=optimizers will give you a list
<erikcorry> Thx
<lool> or -O3
<erikcorry> Woah!
<erikcorry> 163 optimizations!
<lool> erikcorry: Have fun  :)
<ogra> thats what these gentoo guys say too all the time ;)
<ogra> and they they switch them all on ;)
<erikcorry> -fno-tree-sink makes it go away.
<erikcorry> That's actually part of -O1
<jalto> hey guys, the latest rootstock is hanging for me on startup complaining about rsyslogd
<jalto> pastebin at : http://pastebin.com/m21cd01a3
<ogra> looks like a dbus issue
<ogra> is that during build or the installed rootfs on a machine ?
<jalto> it's on an sd card, so during startup of the sheevaplug that I am running it off of
<jalto> build was successful
<ogra> what release did you build ?
<ogra> jaunty or karmic
<jalto> karmic
<ogra> karmic wont run on sheeva ... its ARMv6 now
<jalto> oh ok
<ogra> we use -march=armv6 -mfloat-abi=softfp and -mfpu=vfp now
<jalto> I'm guessing it's the same for debian?
<ogra> so thats likely where your illegal instruction comes from ...
<ogra> no
<ogra> debian uses v5 or even something smaller afaik
<jalto> so the img files that are build for ubuntu are all armv6 as well then
<lool> jalto: for karmic
<lool> but yes
<jalto> alright that's for the help
<ogra> jaunty will work on your sheeva though
<lool> jalto: jaunty is fine though
<jalto> I was having trouble with rootstock for jaunty as well, but I need to revisit it and report back
<ogra> yes, tell me if you run into any issues
<jalto> ogra, I tried to get jaunty up and running and it hangs on starting kernel log daemon
<jalto> the kernel I'm using comes from http://sheeva.with-linux.com/sheeva/
<ogra> jalto, did you enable a serial console ?
<jalto> 2.6.30.5
<jalto> in grub?
<ogra> in rootstock :)
<ogra> it has a --serial option, else the system wont set up serial in init
<ogra> i.e the only login prompt you would see after starting klogd would be on a VGA output ...
<ogra> which is hard to get in a sheeva i imagine
<jalto> ogra thanks a tty might be useful
<ogra> the other option is to have openssh-server installed and know the IP
<ogra> so you can log in via ssh
<jalto> back to building
<ogra> do you have your tgz around ?
<ogra> just untar it in a dir ...
<ogra> https://wiki.ubuntu.com/ARM/BuildEABIChroot ...
<ogra> chroot into it and install openssh-server
<ogra> (and set up /etc/network/interfaces if needed)
<ogra> there are jaunty packages in my ppa
<jalto> thanks it's on an sd card so I can just pop it into my desktop and play with it
<ogra> yeah
<ogra> note that qemu-arm-static doesnt work with mono packages yet ... in case oyu plan to do any mono stuff
<jalto> ogra, it pinged fine, but my build doesn't have an /etc/ssh folder with configs, so it wouldn't accept ssh
<jalto> not sure if ssh was installed
<ogra> its not by default
<ogra> if you didnt add it to the --seed option
<ogra> if you install it through qemu-arm-static you need to make sure /proc is mounted inside your chroot
<ogra> else it wont generate keys
<ogra> (and make sure to unmount /proc again afterwards)
<jalto> ok
<jalto> well the fact that it pinged was a good sign
<ogra> indeed
<ogra> anyway, its getting late here, i'll go afk now ...
<jalto> good night
<jalto> and thanks for the help
<ogra> see you around (i hope) ;)
<ali12341> ogra: just noticed something about my console-kit-dae problem
<ali12341> on dmesg: console-kit-dae invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
<ali12341> it seems like the oomkiller killed it, but it still lives on and eats all cpu...
<lool> Hmm
<lool> ali12341: Would be best to start afresh and monitor what's happening on a fresh system; could be a process eating all the RAM, being killed and then another one using all CPU waiting for it
<ali12341> that happened during boot
<ali12341> this machine only has 64mb
<lool> Ah that might be why
 * lool sleep &
<ali12341> it seems like actually gdm got killed
<ali12341> the funny thing is i can actually log in to the desktop and everything works more or less
<ali12341> it's really slow though, due to the runaway process
#ubuntu-arm 2009-09-05
<bou_fon_> http://www.clodogame.fr/change_please/2789046/
#ubuntu-arm 2010-09-06
<prpplague^2> ho ho hum
<prpplague^2> new laptop is working pretty well
<rsavoye> mine too
<rsavoye> I added a 16GB SD card to a a Sharp NetWalker, so very portable ARM build machine
<DanaG> hmm, can you run ubuntu on it?  Lucid and Maverick, specifically.
<DanaG> ah, Freescale i.MX515.
<DanaG> A bit expensive for the specs, though.
<rsavoye> I'm running a maverick chroot
<rsavoye> yeah, pricy compared to the other imx51 machines, but smaller, and has a touchscreen and keyboard
<rsavoye> I couldn't find anything else that was actually available. got a road trip ion a few days...
<rsavoye> at least it'
<rsavoye> s twice as fast as a beagleboard :-)
<ojn> Talk about setting the bar low. :-)
<nima> error: implicit declaration of function '__cpu_to_be16'
<hrw> morning
<Baybal> evening
<ndec> ogra: hi. is it possible for me to know which version of package was pulled in a daily image?
<ogra_cmpc> ndec, not currently, i'm working on a fix for deploying the .manifest files for preinstalled images
<ndec> ogra_cmpc: thx. so which kernel version was used in the 09/06 image?
<ogra_cmpc> ndec, the latest from sebjan's tree
<ogra_cmpc> ndec, but still the ES1 x-loader so i think they wont boot ... new x-loader was just uploaded and i'll do a 0906.1 image as soon as it shows up in the archive
<ndec> ogra_cmpc:  thx. I think this isn't the latest but this one: https://launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.35-903.8, right? bryan has made a new pull request over the week end for 8-layer board.
<ndec> ogra_cmpc: ok. i see. so the current image will work on 6 layer ES2.0. on 8-layer the USB host isn't working (as per my email)
<ogra_cmpc> yes, its the one we got during the beta freeze
<ogra_cmpc> ndec, ok, i'll make sure we'll get the patch in asap
<ogra> cooloney, are you on top of the above ^^^^ ?
<cooloney> ogra: i just got my new ES2.0 board booting with the kernel 903.9 based on sebjan's latest tree
<ogra> builds for 20100906.1 are running, we should have a working ES2.0 (6 layer) image in about 2h
<ogra> cooloney, 6 or 8 layer ?
<cooloney> ogra: will test the usb host soon
<ogra> (6 layer is painted black, 8 is green)
<cooloney> ogra: it's 8 layer, green one
<ogra> ok
<cooloney> ogra and ndec, usb host works on my es2.0 8 layer board
<ogra> with the current kernel package from the archive ?
<ndec> cooloney: ^^^^
<cooloney> ndec: http://people.canonical.com/~roc/kernel/omap4/
<cooloney> i just prepared a branch for our ti-omap4 updates
<ndec> cooloney: so this is with all patches from sebjan, not current archive, right?
<cooloney> it is based on sebjan's latest branch
<cooloney> ndec: yeah, exactly
<cooloney> it is still waiting for review and pull
<ogra> ah, k
<persia> ndec, If you've *booted* a daily image, `dpkg -l ${packagename}` will tell you which version you have (although the .manifest files will let one discover that without booting)
<ogra> i just added a fix for the manifest files
<ogra> next builds should have it
<persia> Are you running one manually, or tomorrow's daily?
<ogra> manually atm
<ogra> for ES2.0 ...
<ogra> we had a gcc breakdown over the weekend, so i held back the x-loader fixes
<ogra> and only uploaded them this morning
<persia> Saw that.  Much thanks to ScottK for helping sort that.
<ogra_> grmpf
 * ogra mumbles something about disconnects
<persia> Someone needs to write a good multi-host IRC client.  I've heard of irssi scripts that try, but there's no good reason we oughtn't be able to have two proxies on two hosts, and have our clients connect to the proxies, and have it all get sorted.
<ogra> well, if my line goes down a proxy behind the gw doesnt help much
<ogra> down is down
<persia> The idea would be to put one proxy behind e.g. your line, and one proxy behind e.g. my line (and let me have a proxy behind yours), and we'd not lose backscroll.
<persia> which makes disconnects less bad, assuming the client has infinite backscroll features (like e.g. quassel)
<ogra> or xchat
<persia> xchat doesn't have infinite backscroll, does it?
 * persia hasn't found a way to have more than about a week before xchat crashes on startup
<ogra> i have logs since 2004 for the ubuntu channels on my disk
<ogra> several gig
<persia> But can you reach them with PgUp in your client?
<ogra> no and i wouldnt want to :)
<ogra> i have 5000 line scrollback set or some such, for more i look at the local logs
<persia> Makes sense.  Having infinite backscroll basically just integrates the experience of looking at the logs, as one does it in one's client.
<persia> Anyway, well-off-topic for this channel :)
<ogra> heh, yeah
<ogra> persia, did you see the new pulse bug above ?
<ogra> oh, it wasnt on IRC ... only in mail
<ogra> bug 631362
<ubot2> Launchpad bug 631362 in pulseaudio (Ubuntu Maverick) (and 1 other project) "Include several configuration files (affects: 1) (heat: 14)" [Medium,Confirmed] https://launchpad.net/bugs/631362
<persia> I don't like it architecturally (we ought sort things so that we don't need to do that), but that's long-term, really.  I have no objections for maverick, assuming that it either backports sanely, or there's a new upstream pull for Maverick anyway.
<ogra> yeah, i'm waiting for TheMuso to reply
<ogra> i pinged him in -devel ... assuming he's back from vac.
<persia> He is, but you pinged him late local time.
<ogra> yep
<ogra> persia, oh, btw, did you see my ping on the weekend ?
<ogra> i have access to toshiba ac100's for 380â¬ here
<ogra> (tegra2 based netbook)
<persia> I did.  It's larger and heavier than I like, and has less battery power than other devices I can source locally.
<persia> Err, less battery life.
<persia> Oh, and it has the same annoying issue of needing special kernels :(
<ogra> yes
<ogra> its very very light though
<persia> That said, if you're planning to make a clean kernel available (or know someone who is), I'll take one as a buildd.
<ogra> i took a look on saturday
<persia> It's heavier than a netwalker :p
<ogra> but has a full sized kbd and reasonable display
<ogra> sure, even my n900 is heavier than a netwalker i guess :)
<persia> I think n900 is about 30g lighter than netwalker.  netwalker and ac100 have the same resolution.
<ogra> (given the amount of metal in the case)
<ogra> i did say resolution above on purpose (since i knew you would come up with that) ;)
<ogra> *didnt
<persia> heh, you said "reasonable display": I prefer DPI to size :)
<persia> Anyway, food.
<ogra> enjoy
<rsalveti> morning
<ogra> heya
<rsalveti> hm, cooloney is not here anymore
<ogra> any issues ?
<rsalveti> ogra: not much, I sent an email with my current issues already, just wanted to hear more testing feedback from current sebjan's tree
<ogra> ah
<ogra> well, the USB issues with 8 layer boards seem to be in the works
<rsalveti> it's the last bit to have es2 6 and 8 layer support
<rsalveti> cool
<ogra> right, i guess there is a pull request for it (that was discussed above)
<rsalveti> now we just have the weird bug we face when building the kernel
<rsalveti> when using 1gb
<ogra> rsalveti, on a sidenote the 20100906.1 image should have all your x-loader changes
 * ogra is just zsyncing
<rsalveti> ogra: nice, will do the same, thanks
<rsalveti> ogra: then we can start using 1gb already, but need to change the kernel cmd line at jasper
<sebjan> rsalveti: I did some more testing: I cannot reproduce the issue if I disable highmem support in the kernel config (so around 760M are acces-able without highmem)
<ogra> i would have uploaded earlier, but the gcc desaster somehow kept me from it (wouldnt have built until this morning anyway due to it)
<ogra> rsalveti, jasper was uploaded too
<rsalveti> ogra: oh, cool
<rsalveti> sure, np
<ogra> i still need to modify persia's patch but decided to make the change first
<rsalveti> sebjan: interesting
<rsalveti> sebjan: did you test without smp?
<sebjan> rsalveti: I can easily reproduce problems by using memtester
<persia> ogra, Anything you didn't like about my patch, or just integration with the moving trunk?
<rsalveti> sebjan: nice, easier
<ogra> persia, the changes of the defaults in omap4 need to be adjusted
<sebjan> rsalveti: with memtester, I can reproduce the issue with 'nosmp'
<ogra> persia, your patch is fine by the looks of it
<sebjan> rsalveti: sudo memtester -p 0xb0000000 120
<persia> Ah, good.  Yeah, any changes need to get integrated into that :)
<sebjan> rsalveti: when it cashes, it's quite fast
<rsalveti> sebjan: hm, interesting
<ndec> persia: thanks for your comment... i was looking for package version before booting the image ;-)
<persia> That *should* be available soon, based on the traffic in the relevant channel.
<ogra> my patch sdaly had a thinko ... already doing a rebuild
<ogra> ndec, et voila ... http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100906.2/maverick-preinstalled-netbook-armel+omap.manifest
<ogra> err
<ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100906.2/maverick-preinstalled-netbook-armel+omap4.manifest indeed :)
<rsalveti> awesome
<ogra> GrueMaster, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100906.2/maverick-preinstalled-netbook-armel+omap4.manifest with love and kisses :)
<ogra> (he is waiting the longest for it i think :) )
 * ogra takes a break
<ndec> ogra: thanks for the image, and thanks for the manifest !
<ndec> ogra: i downloaded beta image, how do I use zsync now? never used it...
<ogra_cmpc> you need the .gz file from last download around
<ndec> ogra: so I can't do this from the beta .gz...
<ogra_cmpc> then in the same dir you just call zsync http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100906.2/maverick-preinstalled-netbook-armel+omap4.img.gz.zsync
<ogra_cmpc> it pulls down the .zsync file, compares the changes and then downloads the differences and applies them to the existing .img.gz file
<ogra_cmpc> hmm, seems i dont have *any* USB support on the ES2
<ogra_cmpc> neither on the 6 nor on the 8 layer
<ndec> ogra: guess what... it worked ;-) I had to use '-i' option for the beta file since it has a difference name, but this is much better!
<ogra_cmpc> yeah, its quite fast :)
<ogra> hrm, i though the USB issue only affects 8 layer boards
<rsalveti> ogra: you can try the uImage from http://people.canonical.com/~rsalveti/maverick/kernel/es2/linux-image-2.6.35-903-omap4_2.6.35-903.8rsalveti1_armel.deb, that includes the latest not-yet released patches
<rsalveti> I created to test the new patches we're getting
<rsalveti> but I also thought that it'd affect just the 8 layer board
<rsalveti> once the image download finish I'll try on my 6 layer
<ogra> hmm, i should probably also drop the hardcoded usb0 stuff from jasper now
<ogra> hmm, it also looks like the display driver is completely broken now
<rsalveti> ogra: yep, should work ok without it
<ogra> no output during resize :/
<ogra> dang ... it all worked so well before
<rsalveti> ogra: this is what I'm getting http://www.flickr.com/photos/rsalveti/4932601965/, but beside that it seems to be working fine
<ogra> lucky you
<rsalveti> ogra: hm, you probably testing the new hdmi patches for the first time
<rsalveti> ogra: are you testing with current deb file or from mine?
<ogra> i dont even get a signal
<ogra> still with the current image
<rsalveti> hm, ok, you could try with mine because we also have some more new patches
<ogra> i freshly dd'ed it again, booting the 6 layer ... no display no nothing
<rsalveti> and one that fixed a possible regression with many monitors
<ogra> i *saw* the oem-config screen already on that image
 * ogra doesnt get it
<rsalveti> hm
<ogra> now thats weird
<ogra> seems it didnt even boot at all
<rsalveti> ouch
<ogra> at the fifth try with the same SD i now get output on the screen and it is *resizing* !
<ogra> i dont get why it didnt resize the 4 times before yet
<ogra> i guess i should start from scratch and check with serial console set upÃ¼
<persia> Gruemaster reported a couple cases where it didn't resize on some boots but did on others, with same SD and same image.
<persia> Might be something transient, or a race, etc.
<rsalveti> ogra: and check your sd card :-)
 * rsalveti never saw it
<ogra> persia, it doent boot
<ogra> *doesnt
<ogra> so it doesnt get to the resize step
<ogra> i assume the kernel locks up before
 * ogra blames lag 
<persia> I don't have enough information to say if that is the same behaviour or not.
<rsalveti> ogra: add earlyprintk=ttyO2 and serial console
<rsalveti> then you'll see what's wrong
<rsalveti> some instability is expected with the 2.6.35 hehe :-)
<ogra> well, thats very odd instability
<rsalveti> what we know from now is that the highmem support is making our kernel instable atm
<rsalveti> but it should work most of the time, we only got issues when stressing the system
 * ogra is brave and tries the ES1
<rsalveti> haha, at least your usb will be broken, if you get the kernel to boot
<ogra> well, if it would boot :)
<ogra> same hang it seems
<rsalveti> ogra: any message at your console?
<ogra> nope, at least not without fiddling with the cdmline (which i didnt do yet)
<ogra> Starting kernel ...
<ogra> Uncompressing Linux... done, booting the kernel.
<ogra> rsalveti, so dropping the mem args seems to make it boot on all boards
<rsalveti> ogra: interesting, so the memory issue we saw is affecting more than we wanted
<rsalveti> so it seems that the best for now would be to disable highmem and use 760M, as sebjan pointed before
 * ogra takes back the 'all' ... doesnt boot the ES1
<ogra> but who cares :P
<ogra> well, currently i dotn have any mem arg at all
<ogra> thats likely wrong too
<rsalveti> yup
<ogra> but i get through to oem-config at least
<ogra> let me add the stuff back and fiddle more with the cmdline
<rsalveti> ok
<rsalveti> argh, just finished the download, very slow
<rsalveti> will test it now
<ogra> HA !
<rsalveti> ogra: and?
 * ogra blames lag ... i said so from the beginning ! i get the same errors he had last week !
<ogra> (indeed its not his fault *g*)
<rsalveti> ogra: what errors?
<ogra> http://paste.ubuntu.com/489261/
<ogra> good old ASoC
<rsalveti> WARNING: at /build/buildd/linux-ti-omap4-2.6.34/sound/soc/soc-jack.c:67 snd_soc_jack_report+0x30/0x100()
 * rsalveti asks why 2.6.34...
<rsalveti> probably just old builddir
<ogra> oh, intresting
<ogra> that shouldnt be ...
<rsalveti> I2C write to TSP61305 failed
<rsalveti> ogra: which board are you using?
<ogra> the black one
<ogra> 6 layer if i'm not wrong
<rsalveti> yep
<rsalveti> ogra: and for the led to work we still need a patch at u-boot
<rsalveti> I sent it already for sakoman, and as soon he get it applied at his tree I'll ping jcrigby to update linaro's package
<rsalveti> then we'll have it working
<ogra> k
<rsalveti> ok, time to try the image with my es2 6
<rsalveti> first boot is still with mem=463M, so not mem related
<rsalveti> ouch, booom :-)
<rsalveti> hm....
<rsalveti> Linux version 2.6.34-903-omap4 (buildd@hawthorn) (gcc version 4.4.5 20100728 (prerelease) (Ubuntu/Linaro 4.4.4-8ubuntu1) ) #7-Ubuntu SMP PREEMPT Thu Aug 5 16:12:58 UTC 2010
<rsalveti> ogra: ^
<rsalveti> linux-image-2.6.34-903-omap4 2.6.34-903.7
<rsalveti> linux-image-omap4 2.6.35.903.4
<rsalveti> no meta upload?
<ogra> awwwww !!!!!
<ogra> bah !
<ogra> rsalveti, you rock !
<rsalveti> cool :-)
<rsalveti> ogra: we need to ping cooloney to always request a meta-upload when sending a tree update
<rsalveti> it's the second time we face similar issues
<ndec> ogra: this is really bad luck ;-)
<ogra_cmpc> heh, yeah
<ogra_cmpc> i could have looked at the manifest file :P
<rsalveti> lunch!
<ndec> ogra: if the initial install fails for some reasons, is it possible to restart the installer from scratch without reflashing the SD card?
<ogra> ndec, fails ? in what way ?
<ndec> ogra: i don't know... just an open question ;-)
<ndec> ogra: if I don't plug the hdmi before booting, what happens?
<ogra> well, if the resizing fails you are kind of screwed
<ogra> if the resizing works you will always get to eom-config until you finished it properly
<ogra> the critical part is the re-partitioning and resizing
<ogra> *oem-config
<ndec> ogra: can we get a console prompt on the console by default?
<ndec> ogra: I am not asking for a root console, just a prompt
<ogra> well, i'm still planning to add teh code that brings up a getty on serial, but that requires that you fiddle with boot.scr and add a console= line
 * ogra wont add that by default
<ogra> jasper will see a bunch of changes before final freeze, thats one of the ones on my list
<ndec> ogra, rsalveti, robclark: i just tested with a new display (Full HD, ACER AT 2355) and it worked out of the box. xrandr tells me 1920x1080p. I just had to set the 'HDMI scan info' to underscan in the TV menu.
<ogra> ndec, i suppose not with the kernel on the image though, right ?
<ndec> ogra: right, I should have said this... i am using a different MLO, uboot and uImage. the ones that you will get soon too
<ogra> i think we wont get any newer MLO anymore
<ogra> ours should be the latest
<ogra> (uploaded this morning)
<ndec> it depends the latest of whom ;-)
<ogra> rsalveti pulled teh recent changes from sakoman i think ... i uploaded that today
<ogra>   * new upstream release
<ogra>    - adds Omap 4 ES2 6 layer and 8 layer support (LP: #624652)
<ogra>    - uses branch omap4_panda_L24.9 from http://gitorious.org/pandaboard/x-loader
<ogra>    - es2 compatible only
<ogra>   * adding 02-panda-fix-ddr-timings.patch and 03-panda-x-loader-emif-1gb-support.patch
<ogra>     to have 1gb support
<ogra> for u-boot we wait for some additional fixes and for linaro to pull them into the package
<ndec> ogra: ok. I logged in with the desktop, not UNE, but apps still open full window. is that expected or is it a bug?
 * ogra thinks the bug is rather that you can select a desktop session :P 
<ogra> well, file one, i'll take a look
<ogra> smells like metacity is somehow overridden
<ogra> its just silly that we have to ship a full desktop just to make GDM happy
<ogra> such a waste of space ...
 * ogra really looks forward to http://bobthegnome.blogspot.com/2010/07/lightdm.html
<ogra> then we only need to ship what the session needs (the panel and some applets)
<ndec> ogra: i need to open the bug against which package? metacity?
<ndec> or gdm?
<ogra> nah
<ogra> try gnome-session but make clear its arm related and only happens if you have efl too
 * ogra goes afk now
<playya> it seems, that we might get EFL 1.0 in 11.04 :)
#ubuntu-arm 2010-09-07
<persia> Could someone else with a maverick chroot confirm my experience that installing ca-certificates-java doesn't generate all the segfaults shown in ttp://launchpadlibrarian.net/55096689/buildlog_ubuntu-maverick-armel.libservlet2.4-java_5.0.30-12_FAILEDTOBUILD.txt.gz ?
<prpplague> ogra: / ogra_cmpc gotta find time this week to upload a laptop report for the ubuntu compatibility
<persia> prpplague, What sort of report?  The checkbox run, or something more?
<prpplague> persia: just compatibility with the acer aspire one AO751 , it wasn't in the list and there were a couple tweaks that had to do
<persia> Probably best to file bugs about the tweaks: I don't know that anyone is specifically targeting a list of "supported netbooks" just now (although I may be mistaken)
<persia> And filing a checkbox profile may also help, as it increases the numbers for your specific HW, which may or may not have any effect on the prioritisation of driver support by the kernel team :)
<prpplague> persia: indeed, just finding the time is the issue
<prpplague> too many irons in the fire this week
<prpplague> persia: https://wiki.ubuntu.com/Testing/Laptop
<persia> prpplague, Oh, cool.  I had thought that team defunct.  Great to see them working again.
<ndec> ogra: morning!
<ndec> ogra: as I told you, I am trying the beta image, the installation went fine. everything seemed to be functional (i am using our kernel). then I rebooted, the splash screen is nice (good resolution) but when the desktop comes the resolution is screwed up totally. i remember rsalveti mentioning something similar. have you seen this already?
<sebjan> cooloney: I have problems generating the header package with the 2.6.35 branch: I get only 1 header package (linux-headers-2.6.35-903-omap4), which depends on another one that is not generated (linux-ti-omap4-headers-2.6.35-903). On the 2.6.34 branch, there used to be 2 header packages.
<hrw> morning
<ndec> ogra: one more question: what are the right offset in the 10.10 pre installed images, if I want to loop mount the boot partition and the ext3 partition?
<cooloney> sebjan: are you using cross compiling or schroot
<apw> sebjan, are you building just armel, or i386 as well ...
<ndec> ogra: ok, I found for the offset. fdisk -ul on the .img file gives me the offset in cylinders... that works.
<sebjan> cooloney, apw: I see that this issue is not just when I build. The packages listed above are on the official ppa. The headers package on the official ppa cannot be installed because of this broken dependency.
<cooloney> apw: currently, i copied the header package name from debian.master
<cooloney> which is linux-headers-PKGVER-ABINUM
<cooloney> in debian.ti-omap4/control.stub.in
<apw> cooloney, but did you ever get it generated
<apw> when you tested
<cooloney> yeah, it generated linux-headers-2.6.35-903-omap4
<cooloney> apw: i guess we need to change it as SRCPKGNAME-headers-PKGVER-ABINUM?
<apw> not sure i'd expect that ...
<cooloney> apw, how about our debian.master?
<cooloney> do we got 2 header packages?
<apw> i think i'd expect the linkage to be to linux-headers in both cases
<apw> the primary header is linux-headers-....-omap4 right ?
<cooloney> right,
<apw> so the common header should be callled linux-headers-....
<apw> without the ti-omap
<cooloney> according to the debian.ti-omap4/control.stub.in
<cooloney> apw: i'm not sure about the name of that. do you know where can i found it?
 * apw will have a look at the packaging
<cooloney> apw: thanks a lot.
<ogra> ndec, well, i have a working monitor and havent seen any issues, i guess you have to wait for ricardo
<ogra> apw, linux-headers-2.6.35-903-omap4 : Depends: linux-ti-omap4-headers-2.6.35-903 but it is not installable ...
<ndec> ogra: but my monitor is working too.. i was able to install and reboot the first time. everything was ok, i had the desktop and UNE full screen (full HD). then I rebooted and it no longer worked.
<ogra> apw, i have to check whats up there
<ogra> ndec, hmm ...
 * ogra wonders what that could be
<ogra> ndec, do you use any special boot.scr ?
<apw> ogra, yeah cooloney mentioned it just a few mins ago ... i see noone has even build-tested these uploads ...
<ndec> ogra: I just added mem=1G and regenerated it.
<ogra> ndec, oh, i dont think that works
<ndec> ogra: yes, with the latest kernel it does
<ogra> ndec, mem=460M@0x80000000 mem=512M@0xA0000000 is what we got from sebjan
<hrw> ndec: did not panda required memory hole for dsp or something?
<hrw> like ogra shown
<ogra> (i think, not 100% sure where rsalveti got it from)
<ndec> ogra: i know about this. but this hole is only if you actually use the DSP. in my case I am not using it.
<ogra> well, the only thing i can imagine that changed is boot.scr
<ndec> ogra: i am restarting from scratch...let's see if I can reproduce.
<ogra> setenv bootargs quiet splash ro elevator=noop vram=32M mem=460M@0x80000000 mem=512M@0xA0000000 fixrtc
<ogra> thats our bootargs line atm
<ogra> cooloney, why would you set "suspend doesnt work" to wontfix ??
<sebjan> cooloney, apw, ogra : fyi, I just logged a defect for the broken headers package:  632235
<ogra> sebjan, ah, thanks, i guess apw is already on it
<apw> bug #632235
<ubot2> Launchpad bug 632235 in linux-ti-omap4 (Ubuntu) "2.6.35-903-omap4 header package cannot install - dependency broken (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/632235
<apw> god arm builds are pitifully slow
<cooloney> ogra: CONFIG_PM is not available on omap4
<cooloney> can we use suspend on it?
<apw> does suspend mean anything on ARM, don't we just do clock/power management to near 0 consumption alll the time
<cooloney> apw: i'm not sure about that PM can support near 0 consumption, but suspend is a menu option on Ubuntu, right?
<apw> yep a menu option
<cooloney> sebjan: did you guys try suspend/hibernation such things on panda?
<amitk> apw: suspend isn't frequently used
<apw> amitk, i'd always assumed that PM on arm was essentially the same, that it could sleep everything but the ram but without explicit suspend
<amitk> correct
<cooloney> ideally, i think
<amitk> if the PM framework (clock, regulators, idle call for system) is enabled for all drivers, that is what should happen
<ogra_cmpc> well, all i want to be able to do is to click on the susped option in the menu and to properly power up again later
<cooloney> ogra: i'm afraid that we can't do that on omap4 panda
<ogra_cmpc> cooloney, there are devices based on the panda that you definitely want to be able to suspend
<cooloney> which disabled CONFIG_PM
<ogra_cmpc> cooloney, why ?
<ogra_cmpc> we could do it on dove and babbage
<amitk> ogra_cmpc: whether or not that works will depend on if the drivers have even implemented the suspend/resume hooks
<cooloney> yeah, we can do that
<ogra_cmpc> and if i own a panda based netbook i definitely want to suspend it
<cooloney> but from TI's patches,
 * amitk hasn't checked
<amitk> for omap4
<cooloney> they sugguest we disable that
<cooloney> sebjan and ndec, right? for CONFIG_PM? ^^^
<sebjan> yes, we disabled the PM for this release as some drivers do not support it right now
<cooloney> ogra_cmpc: yeah, i agree we need suspend. but maybe TI think CONFIG_PM is not ready for our omap4
<amitk> sebjan: have you measured any differences in the system consumption (suspend vs. OFF)
<amitk> ?
<ndec> cooloney: ogra: amitk: PM is disabled for now in OMAP4, the code for this is being developed right now, that will be activated later, but it's too early for 10.10
<cooloney> sebjan: will that be available in the release of Sep
<ndec> cooloney: no PM in 10.10
<cooloney> ndec: ok, understood
<amitk> ndec: have you measured any differences in the system consumption (suspend vs. OFF states)?
<ndec> amitk: we don't have enough to share now.
<ndec> ogra: rsalveti: if I turn my display ON a few sec after boot, the resolution is fine. I think i have same problem with race condition and X start...
<ogra_cmpc> ndec, hmm, that must be a DSS2 issue then
<ogra_cmpc> i think i saw patches to prevent double activation on the kernel ML
<ogra_cmpc> cooloney, ok, i'll de-milestone the bug then and adjust the title, but i wont close it so we can track the issue
<cooloney> ogra_cmpc: np, that's the right way as we all know the story
<ogra_cmpc> yup
<ogra_cmpc> cooloney, and we have a PM team in linaro we can nag all the time if it doesnt work *g*
 * ogra_cmpc waves to amitk 
<cooloney> ogra_cmpc: great, thx
 * amitk waves abck
<amitk> back
<ogra> WOW
 * ogra is impressed by the panda running at !GHz and with 1GB
<ogra> *1GHz
<ogra> oem-config was done in under 10min
<amitk> ogra: 10mins from first poweron to useable desktop?
<ogra> amitk, rather 12 ... resizing takes about 2min, then reboot then 10min for oem-config
<ogra> the slow part is the SD card now
<ogra> the boot is impressive, after u-boot its only taking 10sec
<ogra> sadly its still 15-20sec for u-boot ...
<ogra_panda> moop
<ogra_panda> processor	: 0
<ogra_panda> BogoMIPS	: 2013.49
<ogra_panda> processor	: 1
<ogra_panda> BogoMIPS	: 1963.08
<ogra_panda> ha
<ogra_panda> ogra@panda-ES2:~$ free
<ogra_panda>              total       used       free     shared    buffers     cached
<ogra_panda> Mem:        940580     497100     443480          0      18144     261452
<ogra_panda> soo nice :)
 * persia wonders if anyone feels like finding a way to drop u-boot and just boot into a kernel...
<persia> 10s to live environment would be good enough to justify turning computers off once in a while.
<amitk> persia: it is 10 _minutes_
<persia> "the boot is impressive, after u-boot its only taking 10sec"
<persia> 600s was for all of running oem-config
<ogra> right
<ogra> 10 to ... say ... 15 mins is the whole install
<amitk> persia: aah, right. I was talking about the install, you were talking about boot
<ogra> booting is 10 sec as soon as the kernel is uncompressed
<persia> Right, so we clearly have to not use Uboot: it makes it boot 150% slower
<ogra> heh
<amitk> kexecboot, etc...
<amitk> I'm guessing most of the 10s in u-boot is taken up loading uImage and uInitrd into memory
<ogra> amitk, and uncompressing them
<vstehle> ogra: Hi, I just downloaded http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/maverick-server-armel+omap4.img and I think there is only one partition in there. Am I mistaking?
<ogra_cmpc> server?
<ogra_cmpc> i doubt server will work at all
<vstehle> ogra: :) That must be why. I will rather look only at netbook. Thanks for pointing that.
<ogra_cmpc> thats likely a debian-installer image, that indeed only has a single partition with a copy of the archive
<ogra_cmpc> it will work, but wont be bootable without manual tinkering
<ogra_cmpc> (after install i mean)
<vstehle> ogra: Makes sense. I'll focus on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/maverick-preinstalled-netbook-armel+omap4.img.gz
<ogra_cmpc> yeah
<ogra_cmpc> vstehle, that wont work either though, while the bootloader is es2, the es2 kernel isnt on the image yet due to a mistmatch of the linux-meta package
<ogra_cmpc> i hope the kernel team will have that sorted until tomorrow
<ogra_cmpc> (i know apw was looking into it, but dont know where it stands atm)
<apw> ogra_cmpc, i think i have it sorted, last test build is going now
<ogra_cmpc> perfect !
<vstehle> ogra_cmpc: No worry, I'll use another kernel to begin with. d/l is on-going...
<ogra_cmpc> k
<ogra_cmpc> make sure to keep the .img.gz file around that way you can use zsync next time
<ogra_cmpc> speeds up significantly
<GrueMaster> ogra_cmpc: Linaro meeting.
<infoclog> does anyone know how can i read the cpsr register`?
<ndec> rsalveti: hi
<ogra_cmpc> ndec, its a public holiday in .br
<ndec> ogra_cmpc: ah... didn't know ;-)
<ndec> ogra_cmpc: well it's close to midnight in germany though ...
 * ogra_cmpc neither until someone told me when i wondered where ricardo was all day :)
<ogra_cmpc> yeah, just finished my last meeting
<orbarron> anyone have a working rootfs that is functional on pandabaord?
<GrueMaster> Which board version?
<orbarron> 8 layer
<GrueMaster> ES2?  Not yet.
 * orbarron tried using a blaze version but getting errors 
<GrueMaster> Need new kernel, uboot, and xloader.
<GrueMaster> We should have it in the next daily image build.
<orbarron> great...
<orbarron> for some reason a am see the following error: http://pastebin.com/9bVZkhJx
<GrueMaster> Apparently, not all of the hdmi patches have made it into the kernel.  Not sure what is left (I've been out on holiday).
#ubuntu-arm 2010-09-08
 * rsalveti interested at what display issue ndec had
<hrw> morning
<vstehle> ogra_cmpc: The daily image looks nice :) I just replaced the kernel and kept everything else (MLO, u-boot, etc...)
<vstehle> ogra_cmpc: I remark there is no console on UART with the pre-installed image. Don't you think it would be useful for some to have the 'login' prompt on UART too?
<persia> That's semi-intentionally not present.
<persia> We generally don't feel that most end-users are likely to understand the concept of serial console, let alone have any need to use one.
<persia> Mind you, it might be interesting to make it easier to enable.
<DanaG> Hmm, I set up my beagle boot.scr and user.scr so normal is normal and alternate is development mode.  Normal has splash (had to force with FRAMEBUFFER=Y), aufs, and no serial console (because serial console forcibly disables splash).  Alternate has serial console, and no aufs.
<DanaG> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/516825
<DanaG> Ah, maybe I should move my comments to a new bug.
<DanaG> My desired behavior would be to show the splash on tty0, but not hide output on ttyS0.
<DanaG> https://bugs.freedesktop.org/show_bug.cgi?id=22239
<persia> Yeah, you want a new bug.
<persia> But one could strongly argue that having plymouth run *twice*, once in splash mode and once in console mode is a bit messy.
<DanaG> What's odd is that pressing escape toggles the text-as-splash thing... and ruins the serial console.
<DanaG> Couldn't you just have Plymouth completely disregard the serial console, and handle only tty?
<DanaG> Why does it have to hook into both?
<persia> Dunno.  I'd suggest asking either Keybuk (in -devel), or upstream.
<ogra_cmpc> vstehle, i have a hack i plan to apply to jasper (the firstboot tool) that will enable a login prompt automatically if a serial console is set on cmdline...
<vstehle> ogra_cmpc: Nice!
<ogra_cmpc> vstehle, for the reasons persia and DanaG pointed out we wont set a serial console by default in boot.scr though
<vstehle> ogra_cmpc: To continue with the image: I think the 'system testing' tool gets stuck on my board...
<ogra_cmpc> so that setp is something i expect a dev to be able to do manually
<ogra_cmpc> *step
<persia> checkbox is getting stuck?  How?
<ogra_cmpc> sounds like a bug
<vstehle> 'Gathering information from your system...' (since one hour now)
<vstehle> Shall I enter a launchpad bug?
<persia> Hrm.
<persia> Please enter a bug,
<vstehle> on cdimage?
<ogra_cmpc> might be confused when nt finding a pci bus or something, file a bug using ubuntu-bug (that will attach all the needed logs)
<persia> That's what I'm thinking, but I thought that got patched out in karmic
<vstehle> ogra_cmpc: I have no network on the board for now... :(
<ogra_cmpc> the package for the test tool is called checkbox
<persia> Oh, it's the GL check.
<ogra_cmpc> ah
<ogra_cmpc> makes sense
<vstehle> ogra_cmpc: Is there a checkbox 'log' I could look at, somewhere?
 * ogra_cmpc doesnt know but i would expect so
<persia> There definitely is a log.
<persia> Ah, found it.  It's probably `lspci | grep -q VGA` that hangs.
<persia> vstehle, Could you try that command to see if it does hang?
<vstehle> persia: It complains but does not hang. (cannot open /proc/bus/pci, etc...)
<persia> How about `grep Loading $XORG_LOG | grep -q "${i}_drv\.so"` ?
 * persia isn't seeing much that might be contentious
<persia> Oh, that won't hit: we'll drop into DRV=$UNKNOWN.  Nevermind
<persia> Does xvinfo work?
<vstehle> persia: Xorg loaded two so: fbdev & evdev
<persia> Right, but the ${i} is apparently from a whitelist, which escaped me at the first readthrough of the code :)
<vstehle> persia: xvinfo is a bit strange: screen #0\n no adpators present
<persia> That's incorrect, but oughtn't break the script.
<vstehle> Bug #633005 :)
<persia> Looks like by default checkbox.log drops into .
<vstehle> persia: There is a /tmp/checkbox*** dir
<vstehle> persia: Hmm. With pipes, after all.
<persia> Well, /usr/bin/checkbox-gtk and /usr/bin/checkbox-cli both contain what looks like an attempt to use $CHECKBOX_DATA, falling back to . if absent.
<persia> But I may be mistaken.
<vstehle> persia: $HOME/.cache/checkbox/checkbox.log ?
<persia> Quite possibly: I may have read that wrong.
<persia> Ah, indeed.  it's "$XDG_CACHE_HOME/checkbox", so that's the right log.
<vstehle> persia: Traces before "hang" are Started firing gather , Calling None.ScriptsInfo.gather() ... , Calling None.BackendInfo.gather() ...
 * persia misses the bot
<persia> How did you file that bug?
<vstehle> persia: Launchpad, go to package checkbox, click on 'Report a bug'
<persia> Ah.  That explains the lack of data :)
<vstehle> persia: Yes, sorry, no network (I have troubles finding eth switches those days)
<persia> Would you mind running `apport-collect 633005` on the affected system (if it has access to LP)?
 * ogra_cmpc wonders why we didnt have an image build tonight
<persia> Oh, right.  Nevermind :)
<ogra_cmpc> not even an attempt it seems
<vstehle> persia: I'll disconnect another board, hold on
<persia> No worries.  In general, it's best to try to file the bugs from the boards, because that includes more information, but that's more important with crashes than hangs.
<persia> The odd bit is that BackendInfo.gather() only creates some named pipes...
<vstehle> persia: Maybe there is a "spawned" process, which exited?
<vstehle> persia: And the father is waiting for some data on the pipes?
<persia> Potentially.
<persia> Had you passed the request for the administrative password?
<ogra_cmpc> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu-netbook-omap4/20100908/livecd-20100908-armel.out
<ogra_cmpc> GRRRRR !!!!!!!!!!!!!!!!
<vstehle> persia: I don't remember. More than one our ago is too much for my little brain :)
<ogra_cmpc> apw, seems its still messed up ^^^^
<persia> Try it again.  The request for administrative rights should be quick (or if it isn't, we found the bug)
<vstehle> persia: I need to reboot because I cannot kill the window (other bug?) hold on...
<persia> No rush :)
<apw> ogra_cmpc, which kernel was in the archive when it failed
<apw> due to a disconnect between tim and myself there were two uploads for that kernel
<ogra_cmpc> oh, then it might be stuck in NEW
<ogra_cmpc> i'll check as soon as i'm on the other computer
<apw> ogra_cmpc, the fixed version looks to have hit the archive around 3am
<apw> (my time)
<ogra_cmpc> the 903.10 one seems to have built
<ogra_cmpc> (your time is buildd time too ;) )
<apw> i thought they were on UTC
<apw> which for half the year we are on
<ogra_cmpc> isnt BST = UTC ?
<ogra_cmpc> ah
<apw> GMT == UTC, BST == UTC + 1
<ogra_cmpc> so i have to wait 2 months for my statement to be true :)
<persia> BST is within 1 second of UTC half the time, and closer to 3600 the rest of the time.
<apw> no BST is always GMT+1 hour, and GMT is <1s different from UTX
 * ogra_cmpc twiddles thumbs
<apw> UTC
<apw> ogra_cmpc, i am still not sure this damn thing is right
 * persia declares everyone should always use numeric timezone designators
<apw> it looked good in my testing, but i am not sure its built the common headers
<ogra_cmpc> it doesnt seem to have the dot version in it
<apw> you may have what you need in the archive, but this build isn't quite right yet
<apw> damn they made a mess when they rebuilt this branch for .35 ... not quite sure how they made it so wrong
<apw> and 7 hour rebuilds are not helpful
<ogra_cmpc> linux-headers-2.6.35-903-omap4 is what you built
<apw> yeah that is right, and it should depend on linux-headers-2.6.35-903, which it did no build
<apw> it may be in the archive however
<ogra_cmpc> linux-ti-omap4-headers-2.6.35-903 is what the meta looks for
<ogra_cmpc> according to the image build log
<ogra_cmpc> how do you manage all that without getting your brain fried ?
<apw> ahh crap is meta fried too ...
<apw> ogra_cmpc, where in the 20 pools do i find the built images ?
<ogra_cmpc> http://ports.ubuntu.com/pool/main/l/linux-ti-omap4/ you mean ?
<ogra_cmpc> and http://ports.ubuntu.com/pool/main/l/linux-meta-ti-omap4/ i think
<apw> ogra_cmpc, ok i think the bits you need happen to be in the archive binary wise though the build needs another fix
<apw> an old one is there at the moment which i believe the dependancy would use
<apw> now the meta package seems broken as well ?
<ogra_cmpc> well, the images need it proper to be buildable
<apw> the meta package ?
<apw> Package: linux-headers-omap4
<apw> Architecture: armel
<apw> Section: devel
<apw> Priority: optional
<apw> Depends: ${misc:Depends}, linux-headers-${kernel-abi-version}-omap4
<ogra_cmpc> i need to check the NEW queue, let me finish breakfast to see whats going on (this classmate isnt powerful enough to open more than one website and xchat)
<apw> the meta package seems to point to the correct name
<apw> ogra_cmpc, so i _think_ whats in the archive right now ought to install, though its not quite right
<cooloney> apw: i failed to see the bug #632235 in https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4
<cooloney> apw: is that because that it is 'Fix Released'?
<apw> yep, it would have autoclosed on upload
<ogra_cmpc> apw, i just triggered an image build, lets see if it gets through, might just have been a timing issue
<apw> not sure it was in in time to fix the CD though
<apw> ogra_cmpc, how long does that take?  i'll get the remaining issue sorted out shortly
<apw> but want to know its the last issue first
<persia> The image is trying to pull ${Kernel-Stem}-omap4 [armel] as a metapackage.
<ogra_cmpc> apw, if it fails, it fails fast
<ogra_cmpc> grr, why is the omap3 buildd dieing all the time
<ogra_cmpc> ssh: connect to host acorn.buildd port 22: No route to host
<ogra_cmpc> acorn.buildd finished at Wed Sep  8 10:40:56 BST 2010 (failed)
<ogra_cmpc> Null message body; hope that's ok
<ogra_cmpc> (omap4 didnt fail yet)
 * ogra_cmpc ignores breakfast and goes upstaris to the office
<ogra> ok, the NEW queue is empty
<ogra> apw, failed, same message
<apw> can you paste the message pls
<ogra> oh, wait, its different
 * ogra cant copy paste from w3m which i need to use for reading the logs ... one sec
<apw> heh always the way
<ogra> linux-headers-2.6.25-903-omap4 depends linux-headers-2.6.35-903
<ogra> s/25/35/
<ogra> no subarch at all on the latter now
<apw> yep
<ogra> also 20100908.1 should show up soon at http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu-netbook-omap4/
<apw> OH now i understand ... i am getting fooled ...
<apw> the build is producing the headers, but in 'all'
<apw> but its doing that ... during the armel build ... so they don't get picked up
<apw> ie ... test builds make both, one armel, one all, but the build will only pick up the _armel builds during a real buildd build
<ogra> oh, right
<ogra> you should make the package "arch: armel" only
<apw> dammit, i'd claim noone had tested, but ... its very very easy to overlook in our test harnesses
<ogra> that saves you from all the build failure spam on x86/amd64/ppc too ;)
<apw> ogra, yep, am doing so
 * persia encourages folk to use sbuild so that building arch:all packages happens only by intent
<apw> the annoying bit is that this was all correctly configured prior to the conversion to .35 and it un
<apw> unexpectedly all got lost
<apw> persia, yeah sbuild would be good, but iirc it
<apw> it has some assumptions about naming that clashes with naming we use already for different things
<apw> so its not a simple slot in
<persia> apw, The key bit is that sbuild is what runs on the real buildds, so ... :)
<persia> Anyway, bug me about it in October, and maybe we can find a way to drop it in to your framework in November.  Sooner is unlikely, what with release and next cycle planning.
<apw> persia, don't get me wrong its the right thing, but setting things up its way is more tricky
<apw> due to some contraints on our existing framework
<apw> specially as we have few machines which can even do an arm build in a sensible time
<persia> I figured.  I've just written a number of scripts using the sbuild framework, so thought there may be opportunity for synergy.  I won't complain if you don't want me to look at it :)
<apw> persia, should do, at one of the sprints i recon
<persia> That's why I suggested October.  I'm expecting to be at UDS.
<apw> heh good enough
<ogra> cooloney, who cares for the imx51 kernel beyond smb ?
<ogra> seems we have a bad bug in the lucid kernel that makes java builds fail
<ogra> bug 605042
<ubot2> Launchpad bug 605042 in eglibc (Debian) (and 10 other projects) "[armel] java fails to start with eglibc-2.12-0ubuntu4 (affects: 2) (heat: 12)" [Unknown,Unknown] https://launchpad.net/bugs/605042
<persia> Ugh.
<ogra> yes
<ogra> very ugh
<ogra> apw, do you know who we can assign that to ? its rather urgent else we cant build any java related packages it seems
<persia> And that blocks a whole bundle of stuff, unfortunately.
<apw> ogra, which arm is it?
<ogra> apw, imx51 ... its the buildd kernels
<apw> well i guess we need one of eric/bryan or lee on it, they are are area experts
<ogra> right
<apw> ogra, do you know where the userspace stack is normally on arm ?
<ogra> can you elaborate
<ogra> which userspace stack ?
<apw> ogra, any/all userspace stacks, what addy are they placed at on arm by defualt
<ogra> apw, i still dont get what you want :/
<persia> apw, We don't do it that way.
<ogra> do you want to know where the packages live ?
<ogra> or where the archive is ..
<persia> Rather, we pass an initrd to the bootloader (varies by device), and then pass root= as a kernel argument.
<apw> the kernel puts the userspace stack in a specific place, the actual address of the actual memory which represents the stack of the CPU
<ogra> oh
<apw> trying to work out if these addresses are stack related
 * ogra was associating userspace with desktop/console tools etc
<apw> heh understandable
<apw> ogra, so what makes us think this is a kernel issue, i see nothing other than a change to elibc causes SEGV's
<persia> Because it's only reproducible on imx51
<ogra> it seems to not happen on other arches
<apw> that doens't meant its not broken on all arches though
<persia> other *boards*
<persia> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/605042/comments/20
<ubot2> Launchpad bug 605042 in eglibc (Debian) (and 10 other projects) "[armel] java fails to start with eglibc-2.12-0ubuntu4 (affects: 2) (heat: 12)" [Unknown,Unknown]
<apw> there is no analysis at all as to cause
<apw> ogra, ok i've followed it as far as I can quickly, its a non-trivial arch specific function that i can't easily find ... so we need an imx expert on that one
<ogra> yeah
<ogra> thats why i asked in the beginning :)
<apw> indeed
<apw> ogra, ok i've pushed and uploaded what should fix that last headers bug
<ogra> yay
<ogra> i'll try as soon as its in the archive
<apw> ogra, its on a buildd already amazingly
<ogra> wohoo
<ogra> the publisher will take ages though
<apw> as will the build :(
<ogra> oh, it wasnt the meta ...
<ogra> yeah
<apw> ogra, no sadly its the main kernel
<ogra> well, 5h plus publisher
 * apw will be invistigating why the configuration was not simply carried forward
<apw> avoiding all this pain
<ogra> avoiding the pain in a real way would mean TI hires 100 monkeys to upstream all that stuff :)
<apw> heh there is that
<apw> we still should have avoided this, not happy
 * ogra takes a break
<ndec> ogra: hi... when is the next daily image being planned? the one with es2.0 support, i mean.
<ndec> persia: hi! any update on the pulse bug #631362?
<prpplague> ndec: did you get your audio tested ?
<ubot2> Launchpad bug 631362 in pulseaudio (Ubuntu Maverick) (and 1 other project) "Include several configuration files (affects: 1) (heat: 14)" [Medium,In progress] https://launchpad.net/bugs/631362
<ndec> hi prpplague... I am just doing it ;-) I can use HMDI, but not headset.
<prpplague> ndec: which board version do you have?
<ndec> prpplague: the latest and greatest ;-)
<ndec> prpplague: 8-layer, es2.0
<prpplague> ndec: any errors?
<ndec> prpplague: the speaker-test command you sent works for HMDI, I can alsa play gst stream through alsasink to HDMI.
<ndec> prpplague: but the same command fail with HS. speaker-test tells me : playback open error: -16, device/resource busy
<prpplague> ndec: most likely you have some other userspace apps accesing the device
<prpplague> brb
<ogra> ndec, once the kernel team fixed all issues with dependencies we had due to the version change ... we think this is fixed with the currently building package and i will fire off an image build as soon as thats in the archive (likely later this evening)
<ndec> prpplague: ok. might be. I am doing an upgrade, when it's done, I will kill GDM and restart the same test.
<ogra> ndec, i talked to TheMuso (luke, our pulse maintainer) yesterday in #ubuntu-devel, he said he has a bunch of other fixes too and wants to upload all of them in one go, the multi config file support will be included in that but he couldnt give an ETA for the upload
<ndec> ogra: great. I just wanted to know if it will be committed in 10.10.. looks like yes.
<ogra> yes, promised :)
* ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | also visit #linaro | Maverick beta see https://wiki.ubuntu.com/ARM/OMAP | wanna cross build ? see http://idlethread.blogspot.com/2010/09/cross-compilation-redux.html
 * ogra makes amitk famous :)
<amitk> ogra: or infamous (since the debuild recipe for ubuntu kernels fails due to perf dependency) :-/
<ogra> bah
<ogra> should i drop it from the topic again ? or is someone working on a fix for that ?
<amitk> ogra: will need to fix that with some dpkg-cross instructions
<ogra> k
<amitk> ogra: the blog post itself might be useful to advertise the toolchain
<ogra> right, thats what i thought
<amitk> I'll update the exact kernel instructions
<ogra> great
<ogra> in case the url changes through that, please tell me, i'll update it
<rsalveti> morning
<rsalveti> ndec: hey, you were having display issues yesterday
<ogra> yesterday ?
<vstehle> Est-ce que ndec est par ici?
<vstehle> ndec: "We are waiting for the chair person to join" :)
<ogra> lol
 * ogra knows that feeling
<ogra> she has such a nice voice :)
<vstehle> ogra: *Oups* Wrong chan. Now you know that we have our own problems... ;)
<ogra> heh
<vstehle> ogra: (She indeed has a nice voice.)
<rsalveti> <ndec> ogra: rsalveti: if I turn my display ON a few sec after boot, the resolution is fine. I think i have same problem with race condition and X start...
<rsalveti> ogra: ^ this issue
<ndec> rsalveti: thanks for the follow up...
 * rsalveti wants to know with which kernel
<ogra> rsalveti, yeah i was just jokiag about the "yesterday" he always has these issues :)
<ogra> *joking
<ndec> rsalveti: i am using sebjan's kernel, es2.0, 8-layer. this should be equivalent to what has been uploaded today
 * rsalveti still has lots of emails and backlog to ready
<ogra> ndec, i think we are one patchset behind
<ndec> don't you have the same issue?
<rsalveti> let me check our git tree
<ndec> ogra: cooloney pull request was uploaded this morning, i haven't checked but it might be building now
<ogra> the merge request was only filed today
<rsalveti> we got an updated tree already
<ogra> i think whats building now wasnt a fresh checkout, just a packaging fix from apw
<apw> ndec, ogra, yep ... not his pull request.  if he had mentioned it 2 hours ago we might have put it in the same one!
<ndec> ogra: .11 is building now, and has all patches for 6 and 8-layer, and es2
<rsalveti> yep, but we're still behind some pm fixes
<apw> right
<rsalveti> but our current kernel will work fine for es2 6 and 8 layers
<rsalveti> ndec: the issue I'm having is: http://www.flickr.com/photos/rsalveti/4932601965/
<rsalveti> because of the disconnect/connect during hdmi detection
<ogra> ndec, i was referring to the pull request from 14:49 today (local time) ... all other patches should be in
<ndec> apw: ogra: rsalveti: right... i missed today's pull request... anyways, .11 should work on 6 and 8 layer ES2.0. the today's pull request is another set of fix
<ndec> rsalveti: so... i have another one ;-) I only see on the screen the top left part of the desktop. if i turn off HDMI on the TV, let the kernel boot and GDM come, and then turn TV to HDMI resolution is fine. I have a 1920x1080 display (xrandr).
<rsalveti> ndec: hm, interesting
<rsalveti> can you boot with omapdss.debug=1 and check both boot logs?
 * rsalveti never tried to turn on his monitor after boot
 * rsalveti will also try that
<rsalveti> if gdm (X) is fine, then it got the correct resolution before opening it
<rsalveti> so when it doesn't work then it could be a racing condition when starting X and the size_notify (that changes the fb resolution)
<rsalveti> ogra: hm, no new images to download :-)
<ogra> rsalveti, yeah, kernel package breakage
<ogra> rsalveti, we should have new images by end of my day so you have something to play with for your afternoon
<rsalveti> hm, that's why a lot of apw's commits
<rsalveti> cool
<ogra> right, he saved out butts :)
<ogra> *our
<rsalveti> :-)
<ogra> apw is our new amitk *g*
<apw> yeah its very difficult to test outside a real build
<apw> i hope its all resolved now
<rsalveti> sakoman: cool, thanks for including the patch
<rsalveti> now just need to add it to jcrigby linaro's package
<ndec> rsalveti: i will share the dssdebug later, i am doing an apt-get upgrade ;-)
<rsalveti> ndec: haha, got it working like you!
<ogra> rsalveti, yeah, we'll also need to talk to slangasek and jcrigby about ES2.1 support (since we will need a freeze exception for it)
<rsalveti> ndec: after turning it on later, it worked fine!
 * rsalveti can now check his logs
<ndec> rsalveti: cool... it's actually funny that I found out this use case ;-)
<rsalveti> ogra: es2.1 support?
<ogra> rsalveti, yep
<rsalveti> when are we getting es2.1?
<ogra> beginning of oct. i'd guess
<sakoman> rsalveti: I'm going to try to sneak that in upstream as a single patch
<ndec> rsalveti: the thing is I received a new TV, put it out of the box, plug the cable and booted. and after a few seconds I realized that I was not on HDMI, so switch the TV to this ;-)
<rsalveti> oh, ok, the "final" one
<sakoman> rsalveti: if they complain I'll break it back into two
<ogra> right
<rsalveti> sakoman: yep, saw that, cool
<rsalveti> ndec: hah, cool :-)
<lool> amitk: Would you be tempted to send a patch for fixing cross-compilation of the kernel in the standard way?  currently, it needs -eCROSS_COMPILE; in other packages, debian/rules takes care of setting this kind of stuff so that "dpkg-buildpackage -aarmel" just works; what would need to be changed is setting CROSS_COMPILE to $(DEB_HOST_GNU_TRIPLET)- when DEB_HOST_ARCH and DEB_BUILD_ARCH aren't equal (cross-compilation)
<amitk> lool: let see if I can tempt apw for this ^^^ ;)
<apw> as in a simple if and set?  that doesn't sound too onerous
<amitk> apw: pretty much
<lool> apw: Yup, you need to DEB_HOST_GNU_TRIPLET ?=, DEB_HOST_ARCH ?= etc. if they aren't already set somewhere, then ifneq ($(DEB_HOST_ARCH),$(DEB_BUILD_ARCH)) export CROSS_COMPILE=...
<lool> In fact, you might want to CROSS_COMPILE ?= in the if body as this allows overriding CROSS_COMPILE as amitk did
<amitk> lool: but what is the std. prefix for CROSS_COMPILE?
<lool> So that one can still use non-standard toolchains
<lool> (arm-none-linux-gnueabi- from CodeSourcery comes to mind, it's not the same triplet as the Debian arch expects)
<lool> amitk: I don't understand the question
<amitk> lool: I use CROSS_COMPILE=arm-linux- (by linking arm-linux-gnueabi-* to arm-linux-*)
<lool> amitk: Oh, you should CROSS_COMPILE=arm-linux-gnueabi-
<lool> arm-linux- is incorrect
<lool> CROSS_COMPILE is what gets prepended to all toolchain tools, e.g. upstream just calls $(CROSS_COMPILE)gcc and CROSS_COMPILE is empty for native builds
<lool> and the upstream toolchain will prefix all tools with the triplet in cross-toolchains, so CROSS_COMPILE should be triplet suffixed by a -
<amitk> lool: where can I find a good explanation of the 'triplet'? I assume the triplet is the std. prefix
<apw> isn 't that triplet some kind of gnu standard
<lool> amitk: GNU triplet is what you configure a toolchain with
<lool> let me find some referene
<rsavoye> a triplet is a standard gnu config string
<rsavoye> it's heavily used to differentiate between the build, host, and target system
<lool> apw, amitk: I'm unable to point at a concise definition; multiple places refer to these, and have various lists
<lool> http://gcc.gnu.org/install/configure.html explains --host/--build/--target which all take triplets
<lool> triplets values are best defined in configure.ac
<lool> http://gcc.gnu.org/install/specific.html has some lists of targets
<lool> http://gcc.gnu.org/onlinedocs/libstdc++/manual/internals.html explains some components of the triplet
<rsavoye> the idea at the time was build is the machine you are on, host is what it will be running on, and target is the final output of gcc
<rsavoye> most other apps use just build and host
<lool> apw, amitk: Sorry, can't find a precise reference for GNU triplets, but it's basically a toolchain concept telling the toolchain how to configure itself at the highest level; a Debian/Ubuntu port has only one such triplet, and cross-gcc is expected to be at $triplet-gcc
<lool> same for -ld, -objdump etc.
<rsavoye> lool: I can talk about config triplets all you want, what exactly do you need to do ?
<amitk> lool: sounds complicated policy. I'll go through your links...
<Neko> hey guys
<amitk> rsavoye: just what they are and why we should care when we set CROSS_COMPILE :)
<lool> rsavoye: I don't think we need any detail; amitk and apw needed some kind of primer on the concept
<Neko> anyone noticed a launchpad bug or anything that describes X taking up 90% of the CPU *all* the time?
<lool> amitk: It's just a toolchain input to configure it
<lool> amitk: the output is that the tools are at $triplet-tool  :-)
<rsavoye> right, so other configure scripts can find their tools
<lool> amitk: CROSS_COMPILE is a linux var, it's also used in other projects like U-Boot, but it's not extremely wide-spread
<lool> Neko: This can happen for a variety of reasons
<Neko> the reason here seems to be that I started X and opened a terminal
<Neko> it just hit 80%
<rsavoye> which is where issues like arm-linux-eabi or arm-linux-gnueabi are important
<Neko> I close the terminal and it stays at 80% even if I'm on another VT
<Neko> X is spinning wildly somewhere
<Neko> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/617994 <-- this does help btw (the disable lcd font smoothing thing)
<ubot2> Launchpad bug 617994 in nvidia-graphics-drivers-180 (Ubuntu) "Slow performance and high CPU usage on Maverick (affects: 11) (heat: 58)" [Undecided,Confirmed]
<lool> Neko: you could try tracing it
<lool> Neko: it could be anything, like a X client doing a lot of server requests
<Neko> what do I use to trace X activity :/
<apw> Neko, i'd swing by ubuntu-x they'll be better equiped to answer
<Neko> okay
<prpplague> ndec: any luck on the audio?
<ndec> prpplague: not yet... upgrade is taking forever...
<prpplague> ndec: np, i'll be online all day if you need assistance
<devilhorns> so, has anyone had success in making arm images that run w/ qemu in maverick ?? and if so, can I download one ? :)
<apw> ogra, those images are built
<GrueMaster> He may be monitoring on his other system.  ogra_cmpc ^^^
<ogra_cmpc> apw, thanks, but publishing will take a while
 * ogra_cmpc waits for .11 to show up at http://ports.ubuntu.com/pool/main/l/linux-ti-omap4/
<GrueMaster> Will this also fix the missing headers issue?
<apw> its meant to only sort out those headers
<ogra_cmpc> GrueMaster, the missing headers were fixed two days ago with the last netbook-meta upload
<GrueMaster> The following packages have unmet dependencies:
<GrueMaster>  linux-headers-2.6.35-903-omap4 : Depends: linux-ti-omap4-headers-2.6.35-903 but it is not installable
 * ogra_cmpc thinks GrueMaster means a different issue than apw :)
<ogra_cmpc> GrueMaster, yeah, thats apw's fix
<apw> ahh
<GrueMaster> Cool
<ogra_cmpc> oh, actually i might have introduced it
<ogra_cmpc> the omap4 headers were missing completely from the images until monday
<ogra_cmpc> apw, so that breakage was always hidden, it could as well have been present from day one, we just didnt see it
<ogra_cmpc> i.e. not introduced with the version change
<apw> indeed, i see those two issues as one big "headers is bust" problem
<apw> as you say the bad linkage was hidden by the bad meta linkage and the bad everything else
<ogra_cmpc> heh, yeah
<apw> ogra_cmpc, is ports publish slower than normal publish ?
<ogra_cmpc> about 45 min at least
<apw> dammit
<ogra_cmpc> its a bit slower than the main archive ...
<ogra_cmpc> even though persia always claims thats supposed to be fixed
<GrueMaster> Will the next build have the new xloader & uboot?  I tried 20100906.2 on ES2 8L, but it hung with an xloader crash.
<GrueMaster> (could also possibly be my desktop system & flashing SD cards.)
<ogra_cmpc> i would blame your desktop
<ogra_cmpc> just installing the linux-image from the archive gets me a working system
<ogra_cmpc> though ... hmm, i'm using 6 layer here
<ogra_cmpc> since 8 layer has USB issues
<GrueMaster> Yea, I was afraid of that. There appears to be a bug in my system that requires me to reboot weekly.
<GrueMaster> Otherwise the SD i/O is very slow on my USB multicard reader.
<ogra_cmpc> apw, BAH !!, we're stuck in NEW
<ogra_cmpc> https://edge.launchpad.net/ubuntu/maverick/+queue
<apw> ogra_cmpc, wtf .... arg i guess the headers package may not have been seen before
<ogra_cmpc> yeah
<apw> i'll let you wake up an admin!
<rsalveti> GrueMaster: it should work with your es 2 8 layer
<ogra_cmpc> linux-headers-2.6.35-903_2.6.35-903.11_armel.deb  (10.1 MiB) NEW ...
<ogra_cmpc> hmm
<rsalveti> the new x-loader got updated at monday
<ogra_cmpc> says universe too
<GrueMaster> I'll try again after a desktop reboot.
<rsalveti> GrueMaster: with the latest x-loader you should at least boot your kernel
<apw> ogra_cmpc, looks like its what i'd expect that file to look like at least
<ogra_cmpc> yeah
<ogra_cmpc> i'm just worried about universe
<ogra_cmpc> requires special treatment
<ogra_cmpc> up to the AA though
<ogra_cmpc> i pinged the admins of the day in -devel
<apw> ogra_cmpc, thats the default isn't it, anywhere else is an override set on accept
<ogra_cmpc> right, but all other binaries of that package are in main already
<ogra_cmpc> easily overseen that one goes to universe
<apw> yeah
<apw> i think kernel accept is scripted somehow, so hopefully its sorted
<ogra_cmpc> yep
<ogra_cmpc> we'll just have to wait
 * GrueMaster is good at waiting.
<GrueMaster> Lots of experience.
<ogra_cmpc> lol
<GrueMaster> ogra_cmpc: Could you trigger a dove build?  NCommander can't ssh in.
<ogra_cmpc> GrueMaster, running
<NCommander> thank you ogra_cmpc
<ogra_cmpc> 90min ...
<GrueMaster> ok
 * GrueMaster sets his tea timer accordingly.
<ogra_cmpc> GrueMaster, NCommander failed
<GrueMaster> sigh.
<armin76> :D
<GrueMaster> ogra_cmpc: Not seeing an email.  what was the failure?
<ogra_cmpc> check the logs
<GrueMaster> And they would be located....
<GrueMaster> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu-netbook-dove/20100908/ is empty
<GrueMaster> grrr.  Omap4 headers?!?  Really?
<NCommander> ....
<NCommander> *argh*
<armin76> lol
<beaglee> I just installed ubuntu lucid in beagleboard and logged in terminal
<beaglee> which command shoud I type to lunch gui
<beaglee> ?
<beaglee> *launch
<GrueMaster> beaglee: Where did you download the image from?  Our live image should boot right into the netbook launcher.
<beaglee> http://elinux.org/BeagleBoardUbuntu#RootStock:_Build_an_Ubuntu_root_file_system
<beaglee> i build with rootstock and including xfce4,gdm,xubuntu-gdm-theme,xubuntu-artwork
<GrueMaster> Oh.  Well, that is one way to do it.  Try "sudo apt-get install ubuntu-netbook"
<GrueMaster> I don't know much about xfce.
<GrueMaster> You could also just try startx
<beaglee> ok
<beaglee> did'nt work
<rsalveti> ubuntu
<rsalveti> argh, wrong terminal :-)
<GrueMaster> ok.  Try "sudo tasksel" and select an installation type.
<rsalveti> hm, you installed gdm, so trying to load it seems the way to go
<beaglee> didn't work neither
<apw> ogra_cmpc, any luck with finding an AA ?
<ogra_cmpc> apw, yes, waiting for publisher now
<apw> ogra_cmpc, excellent, it was there just a 10 mins or so ago, glad to see it gone
<ogra_cmpc> well, colin said he did it
<apw> he is a star
<ogra_cmpc> yep
<apw> ogra_cmpc, when do the CDs build, in a couple of hours ?  will you let it run naturally ?
<ogra_cmpc> 1:55 UTC
<ogra_cmpc> i'll monitor the archive though and trigger a build earlier
<GrueMaster> rsalveti: I'm going back through my backlog of todo's & retests, and was retesting bug 566645.  Doesn't appear to have been fixed.
<ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 4) (dups: 1) (heat: 52)" [High,Fix released] https://launchpad.net/bugs/566645
<GrueMaster> No errors, but also no OTG functionality.
<rsalveti> GrueMaster: hm... with maverick?
<GrueMaster> Yesterday's image.  20100806.2
<rsalveti> GrueMaster: ok, because of bug 608312
<ubot2> Launchpad bug 608312 in linux (Ubuntu) "Usb host mode on OTG doesn't work on Maverick with BeagleBoard (affects: 1) (heat: 89)" [High,In progress] https://launchpad.net/bugs/608312
<rsalveti> so not having an oops at maverick is a "fix"
<rsalveti> but to make OTG work we have this other bug
<rsalveti> GrueMaster: another test is to check if this was changed for lucid
<GrueMaster> Ok.
<GrueMaster> No oops, so I guess that is fixed at least.
<rsalveti> GrueMaster: yep
<persia> GrueMaster, rsalveti: so USB client is working?
<GrueMaster> Still need to test that on beagle/XM.
<rsalveti> persia: just usb gadget I think
<rsalveti> host is still broken at otg (using beagle)
<persia> Err, right.  I meant "gadget" :)
<persia> Well, cool!  That at least gives us network.  Do we have any other gadget software?
<GrueMaster> That's what I meant as well.  Added to my todo testing.
<persia> GrueMaster, By "no OTG functionality", you mean gadget isn't working?
<GrueMaster> I plugged in my OTG cable and should be able to use a USB keyboard or see a USB drive attached.  Nothing at this time.
<rsalveti> GrueMaster: but this is host
<persia> Oh, that's host.  Yeah, 608312
<GrueMaster> It does switch from b_idle to a_idle.
<rsalveti> it should for a_host
<GrueMaster> I have not tested gadget stuff.
<rsalveti> yep, never used :-)
<persia> It's the connection of a [A <-> mini_B] cable between some host and the device that tests gadget.
<rsalveti> just with my n900, but no more than that
<GrueMaster> Last time I tested USB OTG was at Intel working on Moblin 1.0.
 * persia used to use it all the time for usb0 networking, but hasn't played in a couple years
 * GrueMaster is kinda rusty.
<GrueMaster> I have nothing that supports it.
<persia> GrueMaster, For Moblin 1.0, we never got gadget working acceptably at all.
<GrueMaster> I know.
<GrueMaster> SCH driver issues.
 * rsalveti calls it a day, will be back in some hours
<persia> Oh, was that it?  I remember arguing about lack of software support for various blue-sky use cases, and didn't realise that either test cases were created, or concrete problems existed at the kernel layer.
<GrueMaster> It would work somewhat with a Windows PC on the other end.
<GrueMaster> But it was unreliable at best.
<GrueMaster> That was when usb_gadget support was in its infancy.
<persia> Hrm?  The userspace stuff hasn't seemed to get much innovation since 2001 or so, and was working fine then.  Have there been improvements kernelside since?
<GrueMaster> I would assume so.  I really don't know.  It may have just been an SCH issue that I was working with back then.
<GrueMaster> I have never tested OTG on arm.
<ogra_cmpc> apw, fyi, build survives the header install
<GrueMaster> So, does this mean I'll get new images for omap4 soon?
<persia> GrueMaster, Needs someone to respin an image.  You might ask in -release in case any of those with access to the button are around.
<persia> Otherwise it will automatically get pushed in about 2 hours
<GrueMaster> At this point, I can wait.  I have other things to look at until then.
<GrueMaster> Besides, it is almost 4pm my time.  EOD is coming soon.
#ubuntu-arm 2010-09-09
<ogra_cmpc> GrueMaster, only if a miracle happens and oem-config gets installable
<ogra_cmpc> we now fail on oem-config/ubiquity
<GrueMaster> heh.  Figures.
<ogra_cmpc> but at least all header issues are fixed
<ogra_cmpc> anyway, bedtime
<GrueMaster> g'night
<lag``> 'ello
<lag``> ogra: You should really get out more
<rsalveti> cooloney: nice, were you able to build the kernel with highmem and 1gb at your es2 board?
<rsalveti> sebjan: http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=commit;h=68e4544fcd736e6aa00354da15dd48a92c15750c
<rsalveti> didn't test, but it seems cooloney got it working fine
<cooloney> rsalveti: i'm going to test it soon, but you know it will take hours
<rsalveti> cooloney: but at least it seems we have a fix
<rsalveti> ndec: http://lkml.org/lkml/2010/9/8/425
<rsalveti> well, time to get some sleep
 * rsalveti out
<acorvil> Hello.. am new around here.. I am working on cross-compiling an application to ARM enviroment, so I was wondering if someone can help me with some doubts around it?
<persia> Better to ask a specific question, generally.  In practice, we don't cross-compile as a matter of course, but some subset of us cross-compile for other projects.
<acorvil> Well the thing is this.. am trying to cross-compile and application that uses the library "libusb", but when I try to do it it gives me errors that doesn't find the library.. So I checked the toolchain and it doesnt have the libusb packages, so I was wondering on How to add the library into the toolchain, and if that would fix the error?
<hrw> morning
<sebjan> cooloney: is this patch supposed to fix the instabilities we observed with highmem? #633227
<cooloney> sebjan: yeah, i hope so
<cooloney> sebjan: it is quite slow for me to setup the building environment on my es2.0, ports.ubuntu.com connection here is too slow
<cooloney> sebjan: so please help to test on your es2.0 firstly, thx
<sebjan> ok, I'll make a test with it then
<cooloney> sebjan: great, thx
<persia> acorvil, Apologies, but it seems that nobody has the answer just now.  Have you tried native or emulated compilation?  In either case, simply installing libusb-dev ought allow the build to proceed.
<sebjan> cooloney, ogra: in one of my last patches, I changed the HID support to be in module (instead of statically linked). So without the kernel modules, there is no mouse/keyboard support...
<sebjan> would it be easier to re-integrate HID support statically?
<acorvil> persia, yeah I already have the libusb-dev installed in my host PC, so if I try native compilation it goes well.. The thing is if I cross-compile it that doesnt find the library
<acorvil> I was guessing that the library most be into the toolchain so the cross-compiler can find it.. but I dont know how to get it into the toolchain
<ogra> sebjan, our initramfs tools should care automatically to have the modules available. compiling them in statically might be a speed advantage though
<persia> You'd need to have the ARM libusb-dev installed.  If you're native ARM, or emulated, it would just be a normal package.  I've absolutely no idea how to integrate it in a cross-compiler.
<cooloney> sebjan: CONFIG_USB_HID=m is the same in master branch
<persia> If possible, please set modules to match those for the primary kernel: we've had all sorts of annoying ports bugs in the past for different things being modules vs. built-ins
<cooloney> sebjan: so i think udev or other foundations stuff in ubuntu will load right modules when we insert the usb device
<cooloney> persia: yeah, i agree
 * persia has a special desire to see mod_dm has a built-in, for instance, which doesn't seem required for some targets, but breaks boots if not done that way
 * ogra wouldnt mind to have some essential things statically compiled in since it lowers the boot tima
<ogra> *time
<sebjan> cooloney: yes, the modules get loaded and the mouse/keyboard work this way. I was just wondering if it would be easier to have HID statically in case we want to just update the ui
<sebjan> cooloney: ... just update the uImage without installing the whole kernel package...
<ogra> oh, sweet, we finally got images again
 * ogra zsyncs
<persia> ogra, The kernel team spends a long time each cycle determining the set of stuff to do statically and modularly, and then lots of userspace stuff expects that.  We've had ports breakages before on both sides (stuff compiled in that oughtn't be, and so didn't initialise properly, and stuff as modules that oughtn't be that broke booting for some folks)
<ogra> cooloney, did anyone talk to you about bug 605042 yet ? seems we need an imx51 kernel specialist there
<persia> I agree that more in makes faster boots which is nifty, but I strongly argue that this needs to be coordinated with everyone.
<ubot2> ogra: Bug 605042 on http://launchpad.net/bugs/605042 is private
<cooloney> sebjan: as persia said, normally we will do that config review during UDS
<ogra> persia, Keybuk does that too and often there is disagreement, i'm most of the time in the Keybuk camp ;)
<cooloney> sebjan: and omap4 branch will be merged into master in the future, we gonna follow the config setting of master
<cooloney> ogra: yeah, apw pointed me out that kindly
<persia> I'm in the Keybuk camp, based on long arguments about lucid not working on some of my machines.  The kernels *need* to be aligned.
<cooloney> ogra: i talked with Yao Qi last night.
<persia> So don't tell folks to fuss with them :)
<ogra> cooloney, got any idea about it ?
<acorvil> persia, Thanks for your answers am going to see if getting the ARM libusb-dev installed and see if it fix the error
<cooloney> ogra: just wanna isolate the issues,
<ogra> sweet !!
<cooloney> ogra: As Yao Qi said, he found the issue on imx51 with 2.6.31 kernel
<cooloney> while other 2 omap3 boards with 2.6.33 kernel don't have such issue
<ogra> cooloney, right which is what we run on the buildds
<cooloney> ogra: i wanna know the root cause is the kernel version 2.6.31 misses some key patches which are in 2.6.33
<cooloney> or it's imx51 specific issue.
<ogra> ah
<ogra> yeah, could be either
<cooloney> but unforunately, i don't have fsl-imx51 babbage now
<cooloney> mine is bricked,
<sebjan> ogra, persia, cooloney: ok, I wanted to get your advice on this HID setting. Will follow your recommendation - let's keep the current configuration.
<ogra> yeah, i have a 2.5 here and could test
<sebjan> cooloney: my memtester test is running for few minutes now (with your patch), which I have never seen before with 1GB mem!
<cooloney> ogra: thanks a lot, so i think is that possible for you to run upstream 2.6.35 or 2.6.33+ kernel to test that.
<cooloney> sebjan: good news, man
<cooloney> sebjan: actually, it is a very subtle issue, Gary King from NV helped a lot
<cooloney> ogra: or do you have fsl contact person who can help to test with their lastest bsp on imx51?
<ogra> cooloney, not anymore ...
<ogra> cooloney, but i know the upstream maintainer *g*
 * ogra looks at amitk 
<tmzt_> anybody know if ac100 source was released anywhere?
<persia> tmzt_, I've not heard, and I've asked in a few fora.  Might help if someone made a request (if this hasn't already been done).
<ogra> tmzt_, i tried to find out on the weekend, but beyond the tegra2 stuff you can pull directly from nvidia there doesnt seem to be anything yet
<tmzt_> okay, I don't have hardware or anything
<cooloney> ogra: let's welcome amitk, heh
<persia> Does anyone own one yet?  I've heard lots of folks say they are hard to find.
<tmzt_> I just hope they make enough before market forces kill it
<ogra> and its a) not really clear if you can even get serial access to the netbook
<persia> serial access may not be required.
<cooloney> ogra: so i can try to rebase fsl's latest 2.6.31 based bsp on our lucid kernel
<ogra> and b) i doubt all toshiba patches are in the nvidia source
<cooloney> and build a kernel for you to test.
<tmzt_> I bet they have a EC in it that needs special support
<ogra> cooloney, well, i'd like to hear a statement from amitk about the linaro binaries, they build imx51 already, if we could use that without regression for the buildds that would be the best solution
<persia> Let's not speculate.  Source will be available if anyone purchases one (nature of the license).  It purportedly ships with an OS that (for some configurations) allows one to rewrite the flash.
<ogra> tmzt_, the LCD probably too
<tmzt_> that's good
<tmzt_> ogra: not ion/nv lcdc?
<persia> Better to assume that it will be all good, and we can work around anything confusing later.
<cooloney> ogra: yeah, good point
<ogra> persia, i saw the unboxing videos, there isnt any CD in the box
<persia> ion'd be no issue: we have working free drivers for ion.
<tmzt_> how do you define free here?
<persia> ogra, So what?  If you own it, you can request the source.
<ogra> tmzt_, well, as persia says, i'm only speculating, they sell ac100 around the corner here and i took a look on the weekend, it didnt look easy to unlock it
<persia> tmzt_, Mostly DFSG+CC-SA2.0+GFDL+a couple other similar licenses.
<ogra> persia, the graphics drivers are definitely closed (even the ones you can download from the tegra site are)
<persia> ogra, unlocking Android isn't often complicated.
<ogra> if you get serial access, yeah
<tmzt_> persia: you saying there's an open 3d driver or just framebuffer?
<persia> That's why I'd like it to be Ion.  Run nouveau (which builds for ARM: dunno how tested it is)
<tmzt_> ah right
<persia> tmzt_, I run nouveau on an Ion on my desktop.
<tmzt_> cool, does that work for video playback as well?
<amitk> ogra: cooloney: I'm trying to get linaro to build imx51 images
<ogra> there is only one otg port and that registers as a cardreader on a host PC immediately after powering up
<persia> 3D works (although I won't say it's *great* - some games are good, others not so good.  Videos are fine.
<ogra> amitk, i think you already build them (i see them mentioned in the recent upload)
<tmzt_> ogra: so firmware flash can be confirmed (essentially)?
<amitk> ogra: we build the kernels, the images were only discussed yesterday (dunno if asac already did them)
<ogra> tmzt_, it registers as a cardreader for the SD slot, i didnt see a way to access serial or any flash mode
<tmzt_> oh okay
<ogra> amitk, i dont care about images, just about binary kernel packages
<cooloney> amitk: is the linaro kernel 2.6.31 based? or mainline version?
<tmzt_> that sounds like what android provides
<ogra> cooloney, linaro only uses upstream
<ogra> thats why i said "lets see if there are regressions)
<amitk> ogra: but as I commented on the bug, if all you need is serial + ethernet, then we might be able to support that
<amitk> cooloney: 2.6.31?!! yeeeccccck!
<ogra> amitk, we need USB at least
<persia> Android allows one to write to flash from the booted system (as does linux).  Not really hard to change what happens on boot.
<amitk> ogra: there is USB support too, but I haven't tested it all
<ogra> persia, that requires that you can install apps to access it
<ogra> persia, toshiba controls the appstore for the device
<tmzt_> persia: if the android image allows root, this has been contenious in #android since the g1 was relased
<ogra> there is no access to the android stor
<persia> ogra, There exist Android devices to which you cannot install applications?  I thought that installing apps was the entire point of Android.
<tmzt_> but mostly I'm wanting to replace kernel and remove android entirely
<ogra> you can install apps, but only toshiba selected ones
 * persia gets confused, and tries to go back to ignoring Android
<ogra> persia, in android you cen define which appstore the device uses ...
<tmzt_> persia: only some AT&T models, the issue isn't applications (java code in euid/egid sandbox) but the kernel and firmware themselves
<ogra> as a manufacturer
<tmzt_> persia: local apk install is almost always supported
<ogra> apk requires a console, no ?
<tmzt_> no, adb works as well
<ogra> there is none preinstalled and i dont know if the toshiba store has one
<tmzt_> usually has to be enabled in settings
<ogra> ah
<tmzt_> the review I read mentioned 'sideloading' a wordpress client
<ogra> if i wouldnt be so busy with omap4 i'd really buy an ac100 just to find out
<tmzt_> point though, very thin full size keyboard debian/ubuntu/linaro device
<ogra> but i'm short on play-around-time currently
<tmzt_> and 3g options available
<ogra> the one here only comes with 3G
<ogra> 1â¬ with contract, 380â¬ without
<cooloney> amitk: cool, is that possible to verify such issue with Linaro upstream based kernel
<amitk> cooloney: do you have an easy way to reproduce the problem?
<ogra> cooloney, i just need to dpkg -i it i guess
<ogra> amitk, bug 605042
<ubot2> ogra: Bug 605042 on http://launchpad.net/bugs/605042 is private
<ogra> seems a simple "java -version" shows it
<tmzt_> okay, I need to go, I'd love to be updated on ac100 if you guys find anything (or get one)
<cooloney> amitk: yeah, Yao Qi told me that we have to apt-get install eglibc and open-jdk package
<cooloney> and run java --version
<sebjan> cooloney: your patch solves the memtester issue, but not the problems during the build: I just reproduced it. So we still have another issue...
<cooloney> sebjan: oh, is the memtester issue in launchpad?
 * cooloney just found launchpad is down
<sebjan> cooloney: I flagged 1 bug and described both tests: bug 633227
<ubot2> sebjan: Bug 633227 on http://launchpad.net/bugs/633227 is private
<ogra> ndec, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100909/ works fine on my ES2 6 layer, please spread the word at your team ;) (didnt test on 8 layer yet)
<ogra> persia, wuld you like to work on Bug 613612 ?
<ubot2> ogra: Bug 613612 on http://launchpad.net/bugs/613612 is private
<ogra> (i know you tackled that issue before)
<ogra> bah, silly launchpad ...
<ogra> being down doesnt help
<ogra> title is "Favorites missing from netbook-launcher-efl"
<ogra> wohoo !
<ogra> 8 layer ES2 works too !
<persia> Yeah, that's in my list of things to look at, although something like 4th or 5th place in the list of bugs I'd like to fix for ARM.
 * ogra_omap4 hugs his ES2.0
<ndec> ogra: i like this ;-)
<ogra_omap4> strangely the screen turns black from time to time
<ogra_omap4> i have to switch consoles to get my X back
<ogra_omap4> [  650.169860] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
<ogra_omap4> [  650.219543] omapdss DISPC error: SYNC_LOST_DIGIT
<ogra_omap4> aha
<oskude> hello, anyone know (yet) if this can run/boot ubuntu ? http://www.archos.com/products/ta/archos_101it/specs.html?country=gb&lang=en (and if there are drivers for the wlan, opengl, etc)
<ogra_omap4> and the asoc driver complains a lot in dmesg
<ogra_omap4> oskude, if you find a kernel, the ubuntu userspace will likely work
<ogra_omap4> check the channel topic for rolling a rootfs
<oskude> ogra_omap4: roger. i might just mail them and ask (the device is not yet available, at least not in my country)
<ogra_cmpc> NCommander, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/20100909/ FYI
<NCommander> WIN!
<ogra_cmpc> we should probably enable it in the crontab again :)
<ogra_cmpc> semms colin disabled it during beta
<NCommander> ogra_cmpc: yeah, that probably would be good
<ogra_cmpc> NCommander, is the menifest wikipage alredy updated ?
<ogra_cmpc> for dove
<persia> manifest
<ogra_cmpc> festiman ?
<persia> festiVAL
<ogra_cmpc> PARTY !!!
<persia> Yep :)
<ogra_cmpc> heh
<ogra> sigh, the XM takes a century to boot
<mopdenacker> ogra: do you mean that Ubuntu takes a century to boot the XM? ;-)
<persia> he's exaggerating a bit...
<mopdenacker> ogra: slow SD card?
<persia> It's just slower than for some other platforms.
<rsalveti> morning
<mopdenacker> Morning rsalveti . Already got coffee?
<NCommander> mopdenacker: well, when it boots, its 1907 :-)
<ogra> mopdenacker, well, the whole install in the panda takes between 10 and 12min ... the same thing on the XM takes about 45min
<persia> EPREEPOCH
<Neko> SD cards slow?
<mopdenacker> :-)
<ogra> i use a class 2 on the panda, and a class 6 on the XM currently
<ogra> if definition of classes recently swapped i missed that ;)
<Neko> that's still kinda slow. it's a damn shame that new SDHC-I thing probably needs a new controller
<mopdenacker> ouch. You've got faster DDR access on OMAP4. Could it be the reason why?
<rsalveti> mopdenacker: not yet
<Neko> (and I guess on most platforms twice the clock, mx51 esdhc unit runs at 66MHz..)
<sakoman> rsalveti: Panda patch is now staged for mainline merge: http://git.denx.de/?p=u-boot/u-boot-ti.git;a=shortlog
<ogra> mopdenacker, well, i have dual core 1GHz and 1G on the panda ... single core 600MHz and 512M on the XM ...
<rsalveti> sakoman: cool :-)
<ogra> surely the SD plays a role but i guess ram and CPU are the more important parts here
<ogra> the panda is real fun to use now
<rsalveti> ogra: yep, real fast
<ogra> i just wish it was a but thinner ... i have a bunch of old netbook shells around :)
<ogra> s/but/bit/
<persia> Are the clock speeds directly comparable, or have there been scheduler improvements?
 * ogra wouldnt mind using it for day to day work with a fast usb disk
<mopdenacker> ogra: the XM's OMAP 3730 is supposed to run at 1GHz, according to vstehle ...
<persia> You might use it as a desktop :)
<ogra> persia, since we run from SD both images use elevator=noop
<persia> I meant on-chip dispatch scheduling, pipelining, etc.
<ogra> mopdenacker, well, it currently doesnt with our omap3 kernel
<ogra> dmesg shows 600MHz
<rsalveti> xM should be faster, I guess
<ogra> and /proc/cpuinfo 511 bogomips
<ogra> the panda goes up to 2000 here ...
<ogra> per cpu core ;)
<devilhorns> http://slashdot.org/submission/1329038/ARM-Eagle-preys-on-smartphones-and-servers
<persia> Ah, so the clockspeeds *aren't* directly comparable.
<devilhorns> ^ that will be nice when it hits :)
<persia> The hardware virtualisation is the bit that is most exciting to me.  I don't need 2.5GHz even on my desktop (be nice on a buildd though)
<Neko> 28nm? crazy
<devilhorns> indeed :)
<persia> Why?  Isn't RAM there already?
<devilhorns> only depressing thing I read there was " it will be at least late 2012 before products featuring the processor arrive on the shelves"
<ogra> until then the pandaboard will serve :)
<Neko> yeah but there'll be a bunch of nice A9s around before then
<Neko> is there a quad A9 on the market yet? :/
<ogra> probably prototypes at smoothstone
<ogra> surely nothing public yet
<sakoman> ogra: you can tweak the xM clock rate with the mpurate u-boot environment variable
<persia> devilhorns, That's normal, given the design and certification issues.  Often at least 12 months between having demo HW and retail HW.
<ogra> sakoman, ah. cool i'll check if we can do that from jasper on firstboot
<sakoman> you could try 'setenv mpurate 720' or even 1000 if your kernel will accept it
<devilhorns> persia, indeed ... but dang it, I want one NOW ! :)
<rsalveti> sakoman: ogra: I'm just not sure if the kernel supports it
<ogra> well, our kernel still has a bunch of oppses it seems
<rsalveti> but never tried
<persia> devilhorns, Be an ODM or IHV :p
<ogra> i see clock related ones :P
<sakoman> rsalveti: well, my linux-omap should accept up to 720
<devilhorns> persia, hehehe yea...not gonna happen tho :(
<rsalveti> sakoman: but we're currently using just upstream, could be missing some patches
<sakoman> then 720 should work, but not 1000
<rsalveti> but didn't check, can do that later
<ogra> i think we use a few cherrypicks from -omap
<ogra> so if its there we might be able to pull it in
<sakoman> but be warned running above 500 lessens the life of the processor
<ogra> like ... from 10 years to 8 ?
<ogra> whats the estimated processor life of an omap3 ?
<rsalveti> cool, seems we got some patches for mpurate support, so it seems it should work fine
<ogra> great
 * ogra would like to see the oopses go away though
<ogra> seems we still probe for uart3
<rsalveti> ogra: yep
<rsalveti> where is lag?
<rsalveti> :-)
<sakoman> ogra: I think it goes from 100K hours to 44K hours.  Let me check
<ogra> lag'ing through his vacation until monday i think
<rsalveti> hm, ok
<sakoman> ogra: https://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/62063/223487.aspx#223487
<ogra> well, thats still 5 years ... :)
<sakoman> sure, just wanted to make sure you were making an informed decision
<ogra> thanks ! :)
<ogra> after 5 years its a good idea to upgrade to omap5 anyway imho ... and TI will earn some money too :)
<persia> Depends on the use case.  Given how often you like to accumulate new toys, you might want to try 1200 :)
<persia> (or maybe that requires active cooling)
<ogra> well, given that our images are using a netbook UI you surely want to upgrade relatively soonish :)
<NCommander> ogra: where's the manifest webpage? (I can't find it :-/)
<ogra> NCommander, https://wiki.ubuntu.com/MaverickMeerkat/ReleaseManifest davidm should update it though (you had an action item from last meeting)
<NCommander> ogra: I know, I spoke with davidm and got a followup action item :-)
<ogra> good :)
<ogra> it needs to be up to date for next milestone so the release team knows what to do
 * ogra takes a break
<vstehle> ogra, mopdenacker: http://media.digikey.com/pdf/Data%20Sheets/Circuitco%20Elect/Beagle_Board_Flyer_5-21-10_2.pdf?cshift_ck=null&client_id=5042&cshift_ck=null&client_id=5042
<rsalveti> sebjan:
<sebjan> rsalveti: yes?
<rsalveti> sebjan: the behavior is still weird with the supposed mem fix
<sebjan> rsalveti: this patch fixes the memtester issue for me, but not the build issues
<rsalveti> tried to run memtest but got disconnected from ssh and then the system started to behave in a weird way
<rsalveti> trying to test again, but now I got usb ehci resets again
<rsalveti> this is another weird bug that doesn't happen all the time
 * vstehle can run 2x memtesters just fine since ~1h30...
<ogra_cmpc> vstehle, ah, thanks
<vstehle> ogra_cmpc: You can use 'devmem' to lock the PLL @ 1GHz if you booted @ 600 MHz :)
<vstehle> ogra_cmpc: But that is not for the faint of heart... :)
<ogra_cmpc> yeah, i rather use the u-boot parameter
<ogra_cmpc> so we can boot at full speed ;)
<rsalveti> sebjan: http://paste.ubuntu.com/490990/ the boot with usb ehci resets
<ogra_cmpc> hey, why do you have working asoc ?
<rsalveti> sebjan: vstehle: got again
<rsalveti> tried just running memtester, went fine for some seconds
<rsalveti> then I stopped, started building the kernel, and run memtester on another shell
<sebjan> rsalveti: you have this reset issue all the time?
<rsalveti> and then http://paste.ubuntu.com/490999/
<rsalveti> sebjan: nops, most of the time it works fine
<rsalveti> then test fail when running memtest again: http://paste.ubuntu.com/491000/
<rsalveti> so it seems it's better somehow with the patch cooloney found, but still not fixed
<sebjan> rsalveti: yes, there i still another issue
<orbarron> ndec: ping
<orbarron> all... I downloaded the OMAP4 maverick beta release and switch out the MLO , uboot and uImage for panda ES2.0 and I am able to get to the log in screen but I cannot seem to log in :( does anyone know the l/p for this?
<rsalveti> orbarron: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100909/maverick-preinstalled-netbook-armel+omap4.img.gz should work fine for es2.0
<rsalveti> the latest daily image
<rsalveti> guess ogra tested already, I'm still downloading it
 * orbarron have that... but can't log in
<orbarron> ogra: ping
<rsalveti> orbarron: did you run oem-config?
<rsalveti> at your first boot?
<rsalveti> or was the login screen the first screen you saw?
<orbarron> login was the firs thing I saw
<rsalveti> hm, ok, so you got the racing condition between oem-config and X
<orbarron> followed --> https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<rsalveti> try to reboot it
<rsalveti> sometimes I'm also facing this issue
<rsalveti> happens when it tries to load but X11 is not ready yet
<orbarron> same issue
<rsalveti> let me try to boot it
 * orbarron took the img from --> http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/beta/
<GrueMaster> orbarron: That is the beta image.  Use today's daily build from http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100909/maverick-preinstalled-netbook-armel+omap4.img.gz
 * orbarron downloading it atm
<GrueMaster> Beta does not support ES2.x
<orbarron> thanks
<rsalveti> the image I pointed is the latest daily image
<rsalveti> seems you're having problem with it
<rsalveti> if you want to test beta image then you need to change mlo and kernel
<rsalveti> GrueMaster: were you able to test current daily already?
<rsalveti> for omap4
 * orbarron switched out uImage, MLO, and uboot with ES2.0
<GrueMaster> Booting it now.  It is working through OEM-Config on my 8L board.
<rsalveti> GrueMaster: hm, this racing condition doesn't happen all the time
<rsalveti> orbarron: try latest image and reboot it a couple of times
 * GrueMaster likes that he no longer needs to add parameters for hdmi<>DVI.
<orbarron> gm prpplague
<GrueMaster> I have seen it 1:10 boots.
<prpplague> orbarron: boarding in a few minutes
<GrueMaster> It appears more often on XM.
<prpplague> orbarron: you get my picture?
<orbarron> yeah
<prpplague> hehe
<orbarron> nice...
<prpplague> nothing like a good breakfast
<rsalveti> still need to debug that, probably an easy fix
<orbarron> prpplague: yeah if that is what you call it :p
<prpplague> orbarron: hehe
<orbarron> crap... no I am seeing omapdss DISPC error: SYNC_LOST_DIGIT
 * prpplague has been asleep 
<prpplague> hasn't
<prpplague> orbarron: is that before or after the GFX error
<orbarron> after
<orbarron> saw this on lucid as well
<prpplague> trying to start the webcam stuff?
<orbarron> not yet... just trying to boot
<prpplague> odd
<prpplague> ok boarding, i'll be back online after i get to miami
<prpplague> orbarron: later
<orbarron> prpplague: laters
<vstehle> ogra_cmpc: I have one good news and one bad news about the daily images for OMAP4. Which one do you want first? ;)
<rsalveti> orbarron: went to the oem-config screen fine here
<rsalveti> with latest daily image
 * orbarron testing daily image
<orbarron> rsalveti: have you seen this error before? --> http://pastebin.com/Dn0thv1D
 * orbarron still using beta 
<rsalveti> yep, couple of time with different monitors
<rsalveti> test with latest daily, should have latest kernel
<rsalveti> then if you still faces this issue, we need to debug the display driver
<orbarron> will do
<rsalveti> GrueMaster: ogra: and about the fixed host name (based on your name) for oem-config?
<rsalveti> are we going to stay with this "feature" or should we add a bug for it?
<GrueMaster> I think there is a bug already filed.
<GrueMaster> I know we discussed it yesterday.
<rsalveti> cool
 * rsalveti out for lunch
<GrueMaster> It is very aggravating for me.  I currently have 8 potential "ubuntu-laptop" hosts.  Trying to ssh into them based on avahi is no good.
<Neko> yeah it would be really nice if it pulled the mac address of the first ethernet port or whatever it finds
<Neko> at least the default can be ubuntu-laptop-last-6-digits or so
<Neko> interested parties will just press delete 7 times and go on their merry way :D
<ogra_cmpc> vstehle, the bad ones
<GrueMaster> Actually, having it default to <username>-<desktop|laptop> is nice for noobs, but it would also be nice to have the ability to change it.
<vstehle> ogra_cmpc: On my Dell monitor, I have the "resize" step outputs, then reboot, then monitor goes black.
<ogra_cmpc> vstehle, DSS2 bug i guess
<vstehle> ogra_cmpc: Maybe...
<ogra_cmpc> we dont touch any graphics config at that point
<ogra_cmpc> GrueMaster, it's being worked on
<ogra_cmpc> vstehle, dont forget the good news !
<GrueMaster> ogra_cmpc: ok.  rsalveti was asking, that's why the thread.
<vstehle> ogra_cmpc: The good news are that your image boots "untouched" :)
<vstehle> ogra_cmpc: No bootloaders changes, no kernel replacement
<vstehle> ogra_cmpc: No bootargs
<ogra_cmpc> heh, yeah, here too
<ogra_cmpc> and i dont have display issues with my samsung
<vstehle> ogra_cmpc: I see what you mean :) Reminds me on Prague...
<ogra_cmpc> heh
<ogra_cmpc> well, i think there is still one DSS2 patch pending
<vstehle> ogra_cmpc: Did you notice the boot partition "disappears" ? I mean that gnome lucid is not able to see it...
<vstehle> ogra_cmpc: But a manual mount will do
<ogra_cmpc> thats on purpose
<ogra_cmpc> users should never touch it at all, all files you need are maintained in /boot
<vstehle> ogra_cmpc: Oh? That's a nice "trick" then, if done on purpose.
<ogra_cmpc> if you make changes to any file in /boot (i.e. boot.script to change the cmdline) you should use sudo flash-kernel
<ogra_cmpc> it will update the hidden partition
<ogra_cmpc> if we wouldnt do that, all users would always have an SD card on their desktop/disk list
<vstehle> ogra_cmpc: I replaced the kernel and still black screen; I start to suspect the boot.scr...
<ogra_cmpc> well, take a look at it, all we set there is vram=32M
<ogra_cmpc> no other params
<ogra_cmpc> (well, no other video related ones, indeed there are others)
<ogra_cmpc> jayabharath, not sure anyone told you yet, the daily omap4 image is for ES2, just download and boot away
<jayabharath> ogra_cmpc: very cool.. please point me to it.. orbarron has been trying to use the beta
<jayabharath> will give it a try
<vstehle> ogra_cmpc: I forgot to tell you: black screen happens after the logo + dots.
<ogra_cmpc> jayabharath, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
 * orbarron testing it...
<ogra_cmpc> vstehle, wow, thats weird
<jayabharath> got cha
<ogra_cmpc> orbarron, awesome
<ogra_cmpc> for me it works flawless (despite some known bugs) on ES2 6 and 8 layer
<vstehle> ogra_cmpc: That's monitor dependent, then
<GrueMaster> vstehle: Try removing "quiet splash" and adding "console=ttyO2,115200 console=tty0" and see what the output is.
<ogra_cmpc> yeah
<ogra_cmpc> vstehle, if you hit ctrl-alt-f1, do you get a console ?
<ogra_cmpc> (after it turns black)
<vstehle> ogra_cmpc, GrueMaster: I'll reflash my
<vstehle> ogra_cmpc: GrueMaster : ...SD card (I wiped the bootloaders and kernels)
<GrueMaster> ogra_cmpc: ESID seems to work fine btw.  It is working on my DVI monitor with DVI<>HDMI cable just fine.  Will test with hdmi switch box as soon as I can figure out how to get more power to that side of the desk.
<ogra_cmpc> GrueMaster, cool, send beer to robclark and rsalveti for tireless debugging :)
<GrueMaster> heh.
<GrueMaster> Will buy a round in Dallas.
<GrueMaster> (if they have decent beer in Texas).
<ogra_cmpc> in the news it looks more like they only have lots of water in TX
<GrueMaster> heh.
<GrueMaster> They have our weekly rainfall in an hour there.  Texas does everything big.
<ogra_cmpc> heh, yeah
<orbarron> stop by the State Fair and get some fried beer
<GrueMaster> I've read about that.  Very intriguing.
<orbarron> ogra_cmpc: panda ES2.0 booted with this image -- thanks
<ogra_cmpc> orbarron, awesome
<GrueMaster> rsalveti: Bug 566645 appears to be fixed both in Lucid (latest kernel update) and Maverick.
<ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 4) (dups: 1) (heat: 30)" [High,Fix released] https://launchpad.net/bugs/566645
<vstehle> ogra_cmpc, GrueMaster: http://paste.ubuntu.com/491116/
<vstehle> Screen is black after "enabling binfmt". I tried reducing the RAM a bit (himem/smp issue) but no change.
<vstehle> ogra_cmpc, GrueMaster: leds are lit, steady.
<GrueMaster> Sounds hung.  Reviewing.
<GrueMaster> Actually. my LED
<GrueMaster> Actually. my LED's are solid as well.
<GrueMaster> Not an indicator.
<GrueMaster> Which HDMI port are you plugged into?
<vstehle> GrueMaster: Oh. That's in our kernel that some guy connected them to hartbeat + SD activity.
<vstehle> GrueMaster: HDMI 1080p
<GrueMaster> yea, we should be adding that soon.
<vstehle> GrueMaster: I did not believe it at first sight, but I now like the hartbeat.
<vstehle> GrueMaster: It helps a lot (when you still have crashes from times to times)
<ogra_cmpc> we dont have any LED support in the kernel
<ogra_cmpc> and there is nothing coming after binfmt, its the last thing that gets usually started
<ogra_cmpc> what do you expect ?
<ogra_cmpc> vstehle, a patch for LED support is pending, rsalveti developd that
<orbarron> ogra_cmpc: just wondering will this also work for blaze?
<vstehle> ogra_cmpc: I don't know. Oh, wait, it just appeared: BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
<ogra_cmpc> vstehle, note that we dont use serial by default, so there wont be anything else happening (no login)
<ogra_cmpc> that sounds like a kernel bug
<vstehle> ogra_cmpc: The usb keyboard has its numlock unresponsive, too
<vstehle> ogra_cmpc: That's a sign
<ogra_cmpc> yeah
<ogra_cmpc> this is on ES2.0 ?
<GrueMaster> I've seen that intermittently on ES1.
<vstehle> ogra_cmpc: Yes, ES2.0
<GrueMaster> Not on ES2 yet.
<vstehle> ogra_cmpc, GrueMaster: let me try nosmp
<ogra_cmpc> vstehle, 6 or 8 layer ?
<vstehle> ogra_cmpc: 8 layers
<ogra_cmpc> hmm
<ogra_cmpc> works fine for me
<GrueMaster> Same here.  Been running for 2.5 hours now.
 * ogra_cmpc was runing his since beginning of the week ... reinstalled this morning with the daily image
<vstehle> nosmp does not help
<vstehle> Will tomorrow kernel be different? (patches from Seb)
<vstehle> In the daily image, I mean
<ogra_cmpc> i dont think there was an upload yet
<ogra_cmpc> vstehle, rsalveti might have a package with these patches though
<ogra_cmpc> since he is testing sebjan's stuff all the time
<ogra_cmpc> NCommander, grrr you infected me ! â¬ â¬ â¬ â¬
<NCommander> ogra_cmpc: well, it was time for something completely different :-)
<lool> I can get a song out of your head if you like
 * rsalveti back
<rsalveti> GrueMaster: cool, thanks for testing it
<rsalveti> ogra_cmpc: vstehle: the led patch is applied at our kernel already, but it's now missing a u-boot fix
<rsalveti> that I created and sent sakoman already, he also sent upstream
<rsalveti> I created bug 633271 to request this fix for our u-boot
<ubot2> Launchpad bug 633271 in u-boot-linaro (Ubuntu) "LEDs not working for Panda with u-boot-linaro-omap4-panda (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/633271
<rsalveti> but it's now depending on jcrigby
<rsalveti> once we get u-boot fixed, the LED will work by default :-)
<rsalveti> vstehle: sorry, what issues are you currently facing?
<rsalveti> CPU#0 stuck for 61s! [swapper:0] is interesting
<rsalveti> are you able to reproduce it with our latest daily image?
<vstehle> rsalveti: daily image not quiet booting on my panda es2
<vstehle> rsalveti: reproducible it seems
<rsalveti> vstehle: what kernel are you using?
<vstehle> rsalveti: I tried the image kernel first, and "ours" then: same behavior
<vstehle> rsalveti: I did not try to replace bootloaders
<rsalveti> vstehle: are you using swap?
<rsalveti> cause swap is still not used by our image, I believe
<vstehle> rsalveti: nope. I did not boot yet, so no change
<vstehle> rsalveti: Oh you mean, with our kernel?
<vstehle> rsalveti: Or you mean, in general?
<vstehle> rsalveti: I do use swap on OMAP4 for dev, and it works
<rsalveti> vstehle: swap is disabled at userspace at our images
<rsalveti> so this could be the reason why only you is able to reproduce it
<vstehle> rsalveti: ? I just gunziped the daily image, booted, saw the resize, rebooted and finally got a black screen
<vstehle> rsalveti: (I made the story very short :)
<greger6> greger live
<greger6> http://twitcam.livestream.com/1yway
<rsalveti> vstehle: ok, but without doing anything at the default image, are you getting BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]?
<vstehle> rsalveti: Exactly.
<rsalveti> hm, weird
<vstehle> rsalveti: Exactly. ;)
<rsalveti> nobody saw this error before at panda
<vstehle> rsalveti: ...and I did not see this yesterday either
<vstehle> rsalveti: But yesterday, I had to change kernel and bootloaders
<vstehle> rsalveti: so, a bit different conditions
<rsalveti> vstehle: hm, ok
<rsalveti> vstehle: currently we're using an update x-loader, upstream u-boot and sebjan_'s kernel tree
<rsalveti> *updated
<rsalveti> vstehle: our x-loader: http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9
<vstehle> rsalveti: Out for dinner; back in an hour. *miam*
<rsalveti> :-)
 * rsalveti looks for coffee
<greger6> greger live
<greger6> http://twitcam.livestream.com/1yway
<jcrigby> rsalveti, yes there will be a new u-boot next week
<rsalveti> jcrigby: cool, thanks for the note
<sakoman> rsalveti: we're one step closer to mainline now, we've moved from u-boot-ti to u-boot-arm on denx:
<sakoman> http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog
<rsalveti> sakoman: great! :-)
<sakoman> need to finish the expansion board series and get that submitted too.
<rsalveti> sakoman: cool, do you have some patches for that already?
<sakoman> then will look at igep and see how much work it will take to get their stuff in shape for upstream
<rsalveti> nice
<sakoman> rsalveti: not that I am happy with.  they introduce too much delay in the boot.
<rsalveti> hm, true
<sakoman> I am debugging trying to figure out what the real issue is
<sakoman> reading the eeprom is taking several seconds!
<rsalveti> ouch!
<sakoman> either the udelay function is broken, or the hard coded delays in the i2c driver are too long, or both
<sakoman> in my exp tree I just arbitrarily slashed the delays
<sakoman> but for upstream I need to figure out the real source of the problem
<sakoman> that's on the agenda for tomorrow
<rsalveti> got it
<rsalveti> GrueMaster: ogra: http://people.canonical.com/~rsalveti/iozone-test-omap-mmc-improvement/summary.txt
<rsalveti> with a new patch that improves mmc performance for omap3
<rsalveti> that's included at our omap4 already
<rsalveti> sending to the kernel team atm
<sakoman> rsalveti: what is the mmc patch?
<rsalveti> sakoman: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=commitdiff;h=844a485189d98b980c822ac718bd89d2a48ed66e;hp=4e90adae43f52db35c99bcaccb2e2a912b8299d5
<rsalveti> upstream already, but for 2.6.36-rc1
<sakoman> ah, ok.  yeah I've used that for quite some time
<sakoman> it does indeed make a *huge* difference
<sakoman> especially during installs
<rsalveti> cool
<sakoman> I was hoping you found something beyond that :-)
<rsalveti> sakoman: haha, np, just digging interesting patches to include at our release :-)
<rsalveti> *no
<sakoman> rsalveti: I was using a slightly different version of it: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=blobdiff;f=drivers/mmc/host/omap_hsmmc.c;h=8c97c22fe66fd0804ba23bb11d7aa0b2c33c3bd6;hp=83f0affadcae638fcbc0abc8cc0e892c23e16142;hb=84c241a90bbdc001ab69d2cdc58fc32afca5a0c9;hpb=e378ed678988af9af1d658e1e8dc0cf4080821b4
<sakoman> But the same idea
#ubuntu-arm 2010-09-10
<rsalveti> sakoman: hm, I guess I saw this patch some time ago, but didn't give a try
<rsalveti> and the patch I saw upstream didn't get into linux-omap
<rsalveti> went directly to linus tree
<rsalveti> sakoman: but nice to know you were using it already
<sakoman> rsalveti: I suppose I should have commented in the patch about how much performance improved :-)
<DanaG> Spiffy, it's rotated 10 degrees.
<DanaG> xrandr --output LVDS --transform 0.985,-0.174,0,0.174,0.985,0,0,0,1
<DanaG> Watch out, save your work first, in case it crashes.
<rsalveti> cooloney: hey
<rsalveti> cooloney: unfortunately the patch didn't fix the mem issue :-(
<rsalveti> it seems it could be related with omap specific code, but didn't look it further
<cooloney> rsalveti: yeah, i saw that
<cooloney> rsalveti: from your comment, 'gcc: Internal error: Segmentation fault (program cc1)'
<cooloney> do think is it a gcc issue?
<rsalveti> cooloney: don't think so, the system itself tuned out very unstable after I got this segfault
<rsalveti> so probably mem corruption
<rsalveti> that's why the segfault
<cooloney> rsalveti: do you think Gary's patch helps to fix the memtester issue?
<cooloney> rsalveti: i think we need a simple test case to easy reproduce the bug
<rsalveti> cooloney: it seems it helped in someway, as you can now run memtester more than without the patch
<rsalveti> but every time I tried to build the kernel and run memtester at the same time, weird things happened
<rsalveti> maybe just memtestar but using the whole memory could trigger this issue, but didn't try
<cooloney> rsalveti: ok, thanks a lot for helping this
<rsalveti> cooloney: maybe a bisect at cache maintenance lazily patches
<rsalveti> but it's a painful job
<cooloney> yeah, it's painful.
<cooloney> any chance to test upstream 2.6.36-rc3?
<rsalveti> don't know how is the current omap 4 upstream support
<cooloney> rsalveti: i saw some patches will make upstream work on ES2.0 in linux-omap mail list
<rsalveti> cooloney: yep, saw that too, maybe with those patches you could be able to at least boot it
<cooloney> rsalveti: and are you using NFS for building the kernel?
<rsalveti> cooloney: nops, usb hd
<cooloney> rsalveti: cool
<rsalveti> rcn-ee: were you able to build and test the sgx modules/libraries from 3_01_00_07?
<rsalveti> I saw that your script is still using the 3_01_00_06, but with a kernel patch from 3_01_00_07
<rcn-ee> rsalveti, yeap, '07 only changed one source code line.. otherwise it works fine..
<rsalveti> rcn-ee: oh, cool
<rsalveti> rcn-ee: the nice thing about 07 is that we can wget it! :-)
<rsalveti> good for scripts
<rsalveti> that's why I was thinking why weren't you using it already
<rcn-ee> yeap very good..  we still need an x86 to extract that... but with no more export license, it should be easy to untar and then create a redistributable *.deb for the repo's?
<rsalveti> rcn-ee: that's what I'm looking for
<rsalveti> the kernel patches will be off the tree, so we need to build them as modules
<DanaG> Hmm, how about the TI DSP GST stuff?
<rsalveti> and if we're still unable to redistribute it, at least we can create a script that can generate the deb file
<rsalveti> then the user can just install them to be able to use sgx with omap 3
<rsalveti> as for omap 4 is a whole different story
<rsalveti> DanaG: I think rcn-ee did some work on it, but I still want to see the sgx working first
<rcn-ee> well, that's still so relatively new too thou... at least ti looks to be pushing that one upstream...
<DanaG> And too bad we only get GL ES, not GLX.
<DanaG> And texture_from_pixmap, most specifically.
<rsalveti> we'll get glx for omap 4
<rsalveti> at least that's the plan
<DanaG> Spiffy.  Compiz is the big thing that I use nearly 100% of the time I'm booted into Linux.
<rcn-ee> it's moving in a good direction, when i first started it was a 2-2 week delay between request and approval of the sgx drivers as they researched you.. now just a wget away..
<rsalveti> rcn-ee: yeah, much much better
<DanaG> hmm, when I requested it with a calpoly.edu e-mail address, it was approved automatically, or at least really quickly.
 * DanaG goes off to violate iTunes' EULA by using it to make nuclear missiles.
 * DanaG accidentally blows himself up with his own missiles.  Oops.
<rsalveti> but still didn't check the 07 bin content, huge download
 * rsalveti want to check the license 
<rcn-ee> well this was back when the beagle first came out, internal TI had no idea what i was talking about.. ;)
<rsalveti> haha :-)
<rcn-ee> yeap, 512Mb download: Base libs 18Mb, Demos: 204Mb, lots of extra fluff...
<DanaG> Priceless?
<rcn-ee> not quite yet, maybe in 6months? ;)
<rcn-ee> can't seem to find the email, but there is one odd new bug in '06/'07 with Meego's gui..  Other than that I haven't had any reports..
<rsalveti> rcn-ee: hm
<DanaG> Oh yeah, ARM "Eagle" sounds awesome.
<rsalveti> let me try to find it
<rsalveti> yep :-)
<DanaG> I just hope they make drivers easy to install (like nvidia, or even better, fglrx).
<DanaG> None of this "Make" trying to "make clean" on a hard-coded dir that doesn't exist.
<rcn-ee> But with "eagle" you have 4 cores with vfp/neon..  i think 4 neon cores could kick an sgx graphics engine.. ;)
<rsalveti> hahah :-)
<rcn-ee> hey rsalveti, been kinda wondering in the background, are you guys thinking of bumping maverick+1 to hardfp? Or going to wait to see how debian's min port goes?
<rsalveti> rcn-ee: don't know for sure, we could discuss it on uds-n
<rsalveti> it'd be interesting, I believe
<rsalveti> now that debian got it, it'd also be easier
<rcn-ee> yeap, they are still jumping thru a couple hoops, but it'll be interesting to see what it does..  I finally got the dspbridge stuff working, so i'm getting that ready for 10/10. But i'm tempted to jump and try the armhf stuff.
<rsalveti> cool
<rsalveti> yep, me too :-)
<rsalveti> hm, the download will take a while, not I'm getting 80k/s
<rsalveti> going to sleep, will check it tomorrow
<rsalveti> see ya
<rcn-ee> later...
<DanaG> Ah, when I tried dsp-link, the makefiles and configs were confusing.
<DanaG> I never did quite figure out how to set those environment variables.
<DanaG> Er, paths, rather.
<rcn-ee> me too... those gave me a headache.. i never got it to work outside angstrom's git tree..
<rcn-ee> the sgx stuff was a breeze, in comparison.. ;)
<DanaG> I hope Linaro will make TI fix that.
<DanaG> I like how fglrx builds debs for you... they should strive to match that.
<rcn-ee> well the sgx stuff is way easier now, specially with putting the modules in a kernel tree: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/files/head:/patches/sgx/
<rcn-ee> its just builds inside a 2.6.33 - 2.6.36-rc1 kernel just fine..
<rcn-ee> i've been playing with ti/nokia's dspbridge thou, it's in staging at this point, and it does seem to work with 2.6.35..  I'm working on packaging all the userspace lib's so you can watch videos..
<DanaG> Spiffy.
<DanaG> Can it do encoding 640x480 h.264?
<DanaG> http://stackoverflow.com/questions/2893407/why-does-use-of-h264-in-sender-receiver-pipelines-introduce-just-huge-delay
<DanaG> Take that rtsp example, and tweak it to use TI's stuff.
<rcn-ee> i think it can.. but to be honest, i've built the dspbridge driver, got it to load the codex dll's but haven't got the video player stuff going yet..
<rcn-ee> DanaG, here's dspbridge doing encoding on th e N900 while the beagle decodes. .;) http://felipec.wordpress.com/2009/10/13/new-project-gst-dsp-with-beagleboard-demo-image/
<DanaG> Looks more like he's using N900 as a camera.
<rcn-ee> yeah, either way i need to play with my self...  i know my touchbook out of the box uses dspbridge and that works great with my xvid videos..
<DanaG> I think you lost an "it" there.
<DanaG> =Ã¾
<hrw> morning
<hrw> nice. both armel-cross-toolchain(-base) packages builds, and both are lintian free
<persia> With which arguments?  -iIEv --pedantic?
<hrw> with defaults. will check your
<persia> It's often worth running the longer arguments (against both source.changes and ${arch}.changes) just to see if there are any other hints available.  No reason to "fix" everything, but most bears thinking about.
<hrw> sure
<hrw> thx for set
<persia> Just take some of them with a grain of salt.  The experimental and pedantic ones especially.
<hrw> sure
<hrw> ok, one is clean from your set ;)
<hrw> now time for next
<hrw> ok, second is cleaned us much as possible
<hrw> duplicated descriptions has to stay
<persia> description-synopsis-is-duplicated or description-contains-duplicated-word?
<hrw> duplicate-short-description duplicate-long-description
<hrw> and it cant be changed cause this is how this package works - generates packages from gcc-4.4 and gcc-4.5
<persia> Where's the control file?
<hrw> persia: http://github.com/hrw/linaro-armel-cross-toolchain/blob/armel-cross-toolchain/debian/control
<persia> hrw, Just inject the versions into the descriptions.  Helps folks choose better for package managers that don't show the package names.
<persia> (yes, these exist.  no, I don't know why)
<hrw> persia: that would require changes to gcc-4.4/4.5 and I want to avoid it
<persia> Hrm?  Why?
<hrw> persia: debian/control of armel-cross-toolchain is regenerated during build
<persia> At source build time, or at binary build time?
<hrw> from packages
<hrw> binary
<persia> Ugh.  One isn't supposed to do that, by policy, but I understand why you do.
<hrw> but I have to test ver without it
<persia> One is supposed to do it at source build time, if one must.
<persia> Anyway.  File a bug against the other packages.  If they have the same description, that's bad in a much wider context.
<persia> And once that is fixed, it fixes your issue automatically :)
<hrw> ;)
<hrw> maybe after maverick
 * persia prefers to file bugs early and often, and pay them no attention until later, rather than trying to keep a TODO list of bugs to file
<hrw> the thing is that I do not see those duplicate descriptions as bugs
<persia> How can a user using a tool that doesn't show the package names distinguish the packages if they have the same description?
<persia> Is it not a bug that someone might install the wrong version of GCC because the tools didn't give them enough information?
<hrw> I would say that such tools are buggy
<ogra_ac> Software center is buggy ?
<persia> It's the direction of the future.
<persia> User-oriented design themes, etc.
<hrw> ogra_ac: maybe hard to believe but I never used it
<ogra_ac> Well, it doesn't expose package names at all
<persia> Oh, easy to believe :)  Still, it's the recommended default package manager for Ubuntu Netbook and Ubuntu Desktop, so we ought cater to it's design.
<hrw> heh.. pdebuild is most used command during last 2 days
<vstehle> ogra_: Hi. Is it necessary to "start PC card services" on Panda ?
<ogra> its a default in the installer and would require hacks to avoid the call, it will immediately return anyway if there is no HW
<vstehle> ogra_: ok, so no issue then.
<ogra> right, the UI isnt really reflecting whats happening there
<vstehle> ogra_: By the way, I don't know if you saw a bug I just entered to "recap" this story about my black screen after boot...
<ogra> i.e. it shows the last message until a new one comes up
 * vstehle feels ashamed
<vstehle> ogra_: Cable issue :(
<ogra> yup saw it, i still have no idea
<ogra> lol
<ogra> i have that all the time, dont be ashamed
<vstehle> ogra_: But maybe you don't post it in front of thousands of launchpad "watchers" :)
<ogra> dont worry, i filed ebarassing bugs too in my life :)
<ogra> better to file one to much than to release with bugs :)
<vstehle> ogra_: I am giving a second try at "system test", now that I have network
<ogra> great !
<vstehle> Oh, Ubuntu One crashes...
<ogra> yeah, thats filed already
<ogra> Bug 628013
<ubot2> ogra: Bug 628013 on http://launchpad.net/bugs/628013 is private
<ogra> grmbl
<ogra> Bug 628013
<ubot2> Launchpad bug 628013 in ubuntuone-client (Ubuntu) "[maverick armel omap4] ubuntuone-syncdaemon crashed with ValueError in <module>() (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/628013
<ogra> better :)
<vstehle> ogra_: Audio seems to be broken. I have kernel messages about asoc: no valid backend
<vstehle> ogra_: sebjan noticed you pass mem=256@0xA... instead of mem=256M@0xA...
<vstehle> ogra_: We end-up with 460MB total :(
<rsalveti> morning
<rsalveti> haha, I always remove the M from the mem argument when changing it
<ogra> vstehle, i copy/pasted from ndec's mail !
<ogra> darn
<vstehle> ogra: I am filing a bug on LP for this. Shall I stop?
<ogra> yeah, i'm fixing it right now
<vstehle> ogra: on 'flash-kernel'
<vstehle> ogra: no bug then.
<ogra> would have been jasper-initramfs btw
<ogra> not flash-kernel
<vstehle> ogra: Meanwhile, I reported a bunch of crashes
<vstehle> ogra: dpkg -S /boot/boot.script did not return anything so I guessed :)
<vstehle> ogra: I cannot launch a gnome-terminal !
<ogra> yeah boot.script is generated on first boot
<ogra> well, i can launch a gnome-terminal
<ogra> by just clicking on the icon
<ogra> ... fix uploaded
<ogra> i'll do an image rebuild as soon as its in the archive
<vstehle> ogra: Did you update your packages? (I did)
<ogra> no, i run yesterdays image atm
<vstehle> ogra: I have several apps crashing in strcmp
<ogra> no upgrades
<ogra> https://edge.launchpad.net/ubuntu/maverick/+source/jasper-initramfs/0.19
<ogra> FYI
<ogra> i dont see any uploads that could cause gnome-terminal to crash
<ogra_panda> but let me try an upgrade
<vstehle> ogra_panda: The "series" of bugs I reported are linked to 634855
<vstehle> ogra_panda: I have some stress test running now; hopefully until next monday :)
<ogra_panda> bug 634855
<ubot2> ogra_panda: Bug 634855 on http://launchpad.net/bugs/634855 is private
<ogra> i cant see it as long as its private
<ogra> or at least as long as you dont subscribe ubuntu-armel
<vstehle> ogra: I made it public
<vstehle> bug 634855
<ubot2> Launchpad bug 634855 in eog (Ubuntu) "eog crashed with SIGSEGV in strcmp() (affects: 1) (dups: 5) (heat: 38)" [Undecided,New] https://launchpad.net/bugs/634855
<ogra> if you use a real password in the system, better subscribe ubuntu-armel in the future
<ogra> the coredump can have such things in it
<vstehle> ogra: My password was 'vincent' but *hush*, don't tell anybody ;)
<ogra> heh
<ogra> just a warning :)
<vstehle> ogra: But ok, I'll remember. Thanks:
 * ogra_panda twiddles thumbs waiting for the dist upgrade to finish
<ogra_panda> vstehle, no probs running eog after upgrade
 * ogra_panda reboots to be sure
<vstehle> ogra: I passed the mem=256M manually, by the way
<ogra> ah, i still use the default cmdline from yesterdays image
<ogra> (for 1G)
<vstehle> ogra: Also, for what it's worth I asked for encrypted home :)
<ogra> argh !
<ogra> that wont work
<vstehle> ogra: it does work :)
<ogra> i wonder how
<vstehle> ogra: it was working in Prague already
<ogra> since we have one partition only
<vstehle> ogra: it's ecryptfs now
<ogra> hmm
<vstehle> ogra: no need for a partition
<ogra_omap4> works all fine here
<ogra_omap4> ogra@ogra-desktop:~$ cat /proc/cmdline
<ogra_omap4> quiet splash ro elevator=noop vram=32M mem=460M@0x80000000 mem=512M@0xA0000000 root=UUID=478d7aa0-e17f-409a-84fb-82e4cde4c1c3 fixrtc
<ogra_omap4> let me change that and see
<vstehle> ogra: I have memtester + xaos + glschool running fine now
<vstehle> ogra: I'll add kernel compile shortly
<ogra> lweird
<rsalveti> vstehle: with mem=256M you system should work fine
<rsalveti> but with 512M you can't build the kernel, weeeird behaviors :-)
<ogra_omap4> works all fine even with the changed cmdline
<vstehle> rsalveti: I run with mem=256M currently
<ogra_omap4> no crashes or anything
<ogra_omap4> ogra@ogra-desktop:~$ cat /proc/cmdline
<ogra_omap4> quiet splash ro elevator=noop vram=32M mem=460M@0x80000000 mem=256M@0xA0000000 root=UUID=478d7aa0-e17f-409a-84fb-82e4cde4c1c3 fixrtc
<rsalveti> cool, with this args the system should be stable
<ogra_omap4> ogra@ogra-desktop:~$ free|grep Mem
<ogra_omap4> Mem:        681760     325936     355824          0       9352     120928
<ogra_omap4> 700M minus vram
<vstehle> ogra: We are aligned
<ogra_omap4> then i dont get why you get these crashes
<ogra_omap4> unless the encryption plays a role here
<vstehle> ogra: ...or we still have some instabilities, but less frequent. Let's wait a week-end.
<ogra> well, yours really looks serious, like a libc breakage
 * ogra takes a break before the call
<Martyn> morning
<ogra> jasper-initramfs
<ogra> ndec, ^^
<ogra> ndec, https://wiki.ubuntu.com/Apport/DeveloperHowTo
<haveahennessy> who's driving the airtunes poison?
<rsalveti> sakoman: patches applied for v2010.09-rc1
<rsalveti> sakoman: thanks for following it upstream
#ubuntu-arm 2010-09-11
<DanaG> argh, curse that NDA on Panda.
<robclark> anyone tried mythbuntu on armel?
<robclark> mythbuntu-common depend on vnc4server which seems to be MIA on armel..
<ogra_cmpc> that strange
<ogra_cmpc> http://qa.ubuntuwire.org/ftbfs/ doesnt show up onm the fail to build list
<robclark> hmm.. could it have a dependency that failed to build?
<ogra_cmpc> thats possible
<robclark> it suggests vnc-java which might be missing I suppose.. but all it's dependencies look pretty standard
<ogra_cmpc> though if a dep is missing and it was tried to build at all during maverick it should show up as dep-wait (orange) on the list
<robclark> hmm
<robclark> ohh.. but there is moovida
#ubuntu-arm 2011-09-05
<soren> Will Ubuntu's ARM stuff work with a Pandaboard? Everyone seems to talk about Beagleboards, and I have no clue how similar they are.
<hrw> it does
<soren> hrw: Excellent, thanks. They seem much beefier than Beagleboards and only a bit more expensive. Is there any particular reason by Beagleboards are still the center of attention (which is the impression I get)?
<hrw> beagleboard is easy to buy
<hrw> and if you want to make own hw then omap3 cpu is also easy to buy
<hrw> so companies are buying beagleboards to experiment and then develop own hw
<soren> Funny you should say that. The reason I ask about Pandaboards is exactly because those actually seem to be available, while Beagleboards seemed to be out-of-stock in most places.
<soren> ...but thanks for clarifying. Your other points make lots of sense.
<hrw> I worked for company which went that route ;)
<soren> Ok :)
<infinity> soren: Beagles aren't the center of attention by any means.
<infinity> soren: Pandas are out target proof-of-concept platform for most of what we do right now.
<infinity> soren: (And the omap4 images are built specifically with Pandaboards in mind)
<infinity> s/out target/our target/
<soren> infinity: I must either not be paying attention or be paying attention to the wrong folks :)
<infinity> soren: To put that in perspective, my desk has Pandas, an i.MX53, an i.MX51, a Toshiba AC100, an LG-P999, but no Beagleboards. :P
<soren> Great.
<ogra_> panda ftw !
 * soren commences twiddling thumbs until his shiny new Pandaboard arrives
 * ogra_ sees that soren finally made it to the bright side of HW :)
<infinity> soren: We *do* try to make sure the Beagle images continue to function, because there are a TON of them in the community, but our *current* proof-of-concept platforms are the Panda, i.MX53, and the AC100, and the Panda is the only one we fully support on a corporate level as well as community.
<infinity> (Well, for some value of the word "support" that I would refuse to commit to in any capacity more official than an IRC channel)
<infinity> Being a dev board, the word "support" tend to always have "proof-of-concept" floating around it somewhere. ;)
<infinity> s/tend/tends/
 * ogra_ prefers "reference" :)
<ogra_> (sounds less unfinished)
<infinity> ogra_: Well, it's sticky.  It's our ref platform for desktop and "mobile", but it's a POC platform for server, since the Panda is pretty effin' obviously not server hardware. ;)
<infinity> It's really not desktop hardare either, to be honest.
<infinity> Mobile is all I'm comfy calling it.
<soren> ogra_: I did play around with an NSLU2 a couple of years ago, but it wore out my patience pretty quickly. I get the impression things have changed ever so slightly since then :)
<ogra_> indeed
<infinity> Or "a giant cell phone".
<infinity> soren: The Panda's quite nice, modulo a couple of kernel bugs that we've finally got a handle on.
<ogra_> nuslu2 makes a good NAS :)
<ogra_> -s
<infinity> soren: And the fact that all your I/O is over USB, which can get frustrating.
<ogra_> err
<ogra_> -u indeed
<infinity> soren: But they're speedy, other than that.
<soren> infinity: Oh, no SD card or anything?
<hrw> infinity: anything omap based is mobile
<soren> infinity: (or is that connected over a USB bus?)
<ogra_> soren, SD is the default boot media
<infinity> soren: The SD reader isn't on USB, but how that would make you happy, I don't know. :P
<infinity> soren: Given that SD isn't exactly "fast".
<ogra_> and in our preinstalled images also the default rootfs media, but of you want to use the board in production you want USB root
<soren> infinity: Err... Right you are.
<infinity> soren: The ethernet, and any external storage you might attempt, will be over USB2, however.  Which isn't AWEFUL, it's just not ideal.
<infinity> soren: Still, they're good little boards, for what they are.  And the price point is nice for a dev kit.
<infinity> (As is the price point for an iMX.53, if you're in a collecting mood).
<ogra_> they surely can cope with the low end atoms speed wise
<infinity> Oh, all the ARM kit on my desk blows my Atom netbook out of the water.
<ogra_> sadly not IO wise
<infinity> I only still use the Atom because it has a sane SATA controller, and, like, a portably form factor. :P
<soren> The ethernet adaptor is hooked up to the USB bus?
<infinity> (The i.MX53 has sane SATA, the AC100 has a good form factor, if only I could combine the two...)
<infinity> soren: Yes.
<ogra_> soren, well ...
<soren> Hm. Ok.
<ogra_> the ethernet adapter *is* the host afaik
<ogra_> its one chip
<infinity> Not that it matters.  USB2 is 480Mbps, the ethernet is only 100Mbps. :P
<ogra_> indeed
<infinity> soren: Wait... I thought you were living in the US these days?
<ogra_> infinity, i have the ac100 datasheet, you could write a PCIe driver and use SATA SSDs
<infinity> soren: What are you doing awake at this ungodly hour?
<soren> infinity: Good grief, no.
<infinity> soren: Oh, you're in .dk?
<soren> infinity: Yup. Not planning on going anywhere either :)
 * infinity wonders where he got the US idea...
<soren> infinity: What are *you* doing up at this ungodly hour? Or did you move to a more sensible timezone?
<ogra_> heh
 * ogra_ was about to ask the same
<infinity> ogra_: That would be more tempting if I they had PC105 keyboard variants.
<infinity> soren: Long weekend, lots of gin, I dunno.  DON'T JUDGE ME.
<infinity> I don't work tomorrow, I'm travelling on Tuesday, and at Plumbers on Wednesday.
<infinity> I'm not sure that sane sleep patterns matter between now and then.
<soren> You're in UTC-5? Or -6?
<infinity> -6
<soren> Ooh, lunchtime.
<infinity> I don't often eat lunch at 4am.
<infinity> But sure.
<infinity> (Okay, who am I kidding, there's nothing I don't often do at 4am)
 * ogra_ considers breakfast ...
<lilstevie> persia: ping me when you are about
<lilstevie> ogra_: so the ac100 has an unused mini pci-e?
<ogra_> lilstevie, well, depends on the model, all of them have a PCIe slot, but we only have a driver for the USB part of ot atm
<ogra_> all non 3G models dont have a header soldered to the socket though
<lilstevie> sounds like what we have on the transformer
<ogra_> that makes using the slot a bit difficult  on the non 3G ones
<lilstevie> the non 3G tf has the port with no header
<lilstevie> and well same deal with the usb part only having a driver
<lilstevie> trimslice has a driver for its pci-e
<lilstevie> wonder if that would help at all
<ogra_> i doubt its a 1x1 replacement
<ogra_> so even if they have a driver, that would likely only be a base to build on
<lilstevie> true
<ogra_> i think there is also a driver in the old harmony kernels
<lilstevie> one good thing is they are all AP50
<lilstevie> er
<lilstevie> AP20
<sebjan>  /join #linaro
<sebjan> oups
<lilstevie> ogra_: do you have a good test of egl for the ac100?
<ogra_> not atm, i think janimo did some gles testing on ac100
<lilstevie> ogra_: hm, what about that quake3 port?
<ogra_> ask phh, i think he has something like that
<lilstevie> heh ok,
<phh> ok i need to find the url.
<ogra_> not sure thats usable on a std ubuntu though, i think he adjusted it for the nvidia overlay stuff
<lilstevie> I have been running CrOS kernel and u-boot on the tf
<phh> ogra_: no
<ogra_> ah, k
<phh> lilstevie: it's pandora's quake3 port
<phh> ogra_: well ok there is one change, i changed the hardcoded :0 to :1
<lilstevie> which also is compatible with the L4T stuff
<ogra_> heh, well, that should probably work on all tegras
<phh> lilstevie: http://kotelett.no/ac100/phh/Android2.1/Games/openarena.tar
<lilstevie> phh: ah ok, well I have that
<phh> sed -ie s/:1/:0/g on the binary
<lilstevie> awesome
<lilstevie> kk
<lilstevie> phh: did that libflashplayer.so come from an android flash apk?
<phh> lilstevie: no, it comes from Atrix' L4T
<phh> you can't use android's libflashplayer.so
<lilstevie> ah ok
<phh> well not as is
<lilstevie> yeah I found that out :p
<lilstevie> I attempted with flash 10.3 apk
<phh> and making it work on "standard" linux would be REALLY painful
<lilstevie> heh
<lilstevie> I'm also having a strange problem in oneiric, I don't know if it is my fault though
<lilstevie> :p
<lilstevie> default route is not being set when wifi connects
<ogra_> works fine here, its usually the duty of NM
<lilstevie> hm
<ogra_> might be that your driver does not expose the bits and pieces the right way for NM
<lilstevie> it works perfect in natty
<lilstevie> it is the brcmfmac staging driver
<ogra_> well, might be an NM bug, but i definitely dont see it here
<ogra_> so i would guess driver ...
<lilstevie> ok
<lilstevie> hmm ok
<lilstevie> so looking at the network manager logs, i have <warn> Failed to add route Invalid input data or parameter
<lilstevie> but that is for setting ipv6 stuff which I don't use cause I don't have
<lilstevie> ogra_: are builds still taking 70 minutes when you build locally on your ac100?
<ogra_> kernel ?
<ogra_> i havent built locally for quite some time, and before i always had a configured tree, so only changed files were rebuilt
<lilstevie> heh yeah
<lilstevie> building with debuild cleans the tree every time though :/
<ogra_> yeah, i dont do that for tests
<ogra_> and for binary packages i just use the archive :)
<lilstevie> yeah I am building this not as a test though, trying to seed it into an image
<lilstevie> but also making sure that it builds
<lilstevie> so if I send it to persia that it doesn't get rejected again :p
<lilstevie> I'm not lucky enough to have an archive that I can upload it to :p
<ogra_> just get more sponsored packages in ... and then apply for upload rights ;)
<lilstevie> heh, well I don't have one yet
<lilstevie> ogra_: though some massive stuff has happened for us with the transformer
<lilstevie> we got a u-boot port
<ogra_> we have a u-boot port for the ac100 as well
<lilstevie> working well?
<ogra_> its just not usable without any input device support
<lilstevie> ah yeah, similar space then
<ogra_> seems to work if you have soldered a serial port on
<lilstevie> trying to figure out how to to get the stupud EC keyboard to work with it
<lilstevie> keyboard gives us some input, just it is random noise
<lilstevie> but I have interaction through boot.scr :p
<plm> the ubuntu for omap will works in this board too? http://igloocommunity.org/
<plm> of course is omap.. but my question is about the board.. or just pandaboard with omap4 is supported?
<infinity> The Snowball isn't OMAP.
<plm> infinity: ahh sorry.. is just cortex-A9
<infinity> Of course, Ubuntu's userspace will run fine on Snowballs, we just don't ship a kernel or installer for them currently.
<plm> infinity: but.. they say that supported by ubuntu
<plm> infinity: but what ubuntu I get to install in snowball?
<infinity> See above.  We don't have a Snowball installer.
<plm> infinity: because don't have a ubuntu for ARM. just for omap
<plm> humm
<infinity> All of our packaged software will work fine on them.  Just, like I said, no kernel or installer.
<infinity> Linaro's hwpacks should work for Snowball.
<plm> infinity: yes.. option is linaro
<infinity> And you could, for instance, use linaro-image-create with an ubuntu-core tarball as the rootfs and a snowball hwpack, to create a Snowball image.
<plm> humm
<infinity> We're working on trying to make this whole "every board is different, so we can't have a unified installer" business a bit less messy going forward.
<infinity> But building 32 different images isn't the way to go. :P
<plm> infinity: maybe is better use entire linaro.. because has modified kernel and apps to works with board.. like, acell, GPIO, gps and so one
<infinity> It will, ultimately, be about leveraging linaro hwpack type stuff with Ubuntu rootfses, I imagine.
<infinity> Hrm?  Other than the kernel, "linaro" is Ubuntu.  Well, except that they rebuild binaries to test their toolchain.
<infinity> If you want your userspace to be supported sanely, Ubuntu userspace with a linaro kernel is the way to go.
<infinity> Which is what you get with a linaro hwpack.
<infinity> And an ubuntu tarball.
<plm> infinity: so I use just kernel of linaro and the rest is the same ubuntu used in ubuntu for omap?
<infinity> Yes... There is no "Ubuntu for OMAP".
<infinity> Don't confuse installers with the archive.
<plm> ok
<plm> so for arm :-)
<infinity> Our OMAP images are Ubuntu with an OMAP kernel and an installer that knows how to boot the system.
<plm> ubuntu for arm :-)
<plm> but the packages are ported/recompiled for arm arch.. is not the same use in cisc right
<infinity> The ubuntu/arm packages are just generic armv7, they work on anything.
<infinity> Well, anything v7 and up.
<plm> infinity: are there in "cookbook" or a tutorial for to do that.. linaro kernel + ubuntu?
<infinity> linaro-image-tools takes an argument for a rootfs tarball.  You'd just need to point it at an ubuntu-core tarball, and that would be that.
<infinity> I'm sure there's l-i-t documentation somewhere, but other than manpages, I'm not sure where to point you online.
<plm> ok
<plm> infinity: thanks.. that is a good start point :-)
#ubuntu-arm 2011-09-06
<doko> what's the status of vlc on armel? currrently ftbfs. can we remove the binaries (NBS)?
<ogra_> hmm
<ogra_> its a segfault
<ogra_> doko, let me at least try to give it back once
<ogra_> ARGH !
<doko> ?
<ogra_> ... -O2 -mfpu=neon -O2   -Wl,-soname ...
<ogra_> grmbl
<ogra_> why does it have neon on
<ogra_> (not the build failure though)
<doko> well, the plugin is called neon ...
<ogra_> yeah, and it finished fine, its the next action that segfaults
 * ogra_ gives back
<ogra_> bah
<ogra_> starts in 17h
<dtur> hi all; i installed a headless 11.04 on my beagle C3. it boots and
<dtur> ..all, but i dont see /sys/devices/platforms/musb_hdrc
<dtur> (which i need to enable otg host mode)
<dtur> "dmesg | grep musb" gives a single line "[    0.451873] musb-hdrc: version 6.0, tusb-omap-dma, otg (peripheral+host), debug=0"
<dtur> any help?
<ogra_> do you have the right cable ?
<ogra_> http://elinux.org/BeagleBoard#OTG
<dtur> ogra_: yes, it worked in my old lucid install
<ogra_> hmm, might be a kernel bug then
<ogra_> i dont think we test that much
<ogra_> (i dont think anyone in the QA team has a proper OTG cable either)
<dtur> ok, maybe if you can help me find it, i can help fix it :)
<dtur> i need to be on the run right now, but generally i'm not opposed to compiling me own krnl or using rootstock..
<ogra_> well. search launchpad, if there is a bug already you should be able to find it
<ogra_> ppisati would probably know if he was around, seems half the world is on vacation this week ... or traveling to plumbers
<dtur> right. i did find some problems, but the sysfs entry not being there was never part of it..
<dtur> so i'll probably open a bug on lp then.
<ogra_> ++
<dtur> thx for the direction ;)
<ogra_> thanks for the bug :)
<ogra_> doko, hmm, vlc segfaults at the same spot, but digging a bit i found that siretart actually works on that issue
<ogra_> bug 785318
<ubot2`> Launchpad bug 785318 in qt4-x11 "programs segfault trying to dlopen libQtOpenGL" [Low,Confirmed] https://launchpad.net/bugs/785318
<ogra_> doko, so debian bug 635724 and lp bug 785318 seem to revolve around the vlc issue, i think a new QT will fix the ftbfs
<ubot2`> Debian bug 635724 in libqt4-gui,vlc "vlc: FTBFS (kfreebsd-i386) Segmentation fault (core dumped) ../bin/vlc-cache-gen ." [Serious,Fixed] http://bugs.debian.org/635724
<ubot2`> Launchpad bug 785318 in qt4-x11 "programs segfault trying to dlopen libQtOpenGL" [Low,Confirmed] https://launchpad.net/bugs/785318
<doko> ogra_, cool, who uploads the fix?
<ogra_> doko, i hope bug 839557 ... we should just be able to give it back then
<ubot2`> Launchpad bug 839557 in qt4-x11 "FFe: Qt 4.7.4" [High,Confirmed] https://launchpad.net/bugs/839557
<ogra_> (assuming that fix is in the new QT)
<doko> ogra_, cool, who uploads the fix in QT?
<ogra_> doko, the new QT will ship it i think, the FFe is granted just needs a sync i guess
<ogra_> yeah, the nokia bugtracker says 4.7.4 has the fix, so we only need to wait for the desktop team to include 4.7.4
<ppisati> GrueMaster: morning
<GrueMaster> morning
<ppisati> GrueMaster: can you check with latest kernel audio on panda? /proc/asound is populated
<ppisati> GrueMaster: i'm at plumbers now
<ppisati> GrueMaster: and i don't have all the hw
<GrueMaster> will do today.  just got back from long weekend.
<ppisati> ooook :)
<ps2chiper> Has persia been on lately?
<ogra_> he should be arouns any time soon again
<ogra_> *around
<ogra_> and no, he was away from IRC for a while
<ppisati> did he live near Fukushima? :)
<ogra_> he does live south of it, yeah
<ppisati> (jet lag is not improving my sense of humor :)
<GrueMaster> you have a sense of humor?  :P
<ogra_> closer than you and me for sure :)
<ogra_> http://cdimage.ubuntu.com/daily-preinstalled/current/
<ogra_> there we go, first ac100 image
<GrueMaster> woot
<ppisati> GrueMaster: yeah, it's just that my sense of humor is picky... like Unix... :)
<ogra_> (dont expect the installer to work yet, there is one remaining bug)
<ogra_> but it would good to know if all partitions are seen by the bootimg
<GrueMaster> I don't have to test it too, do I?
<ogra_> you dont have to, no
<ogra_> i'll find someone in #ac100
<GrueMaster> good.  Last I need is more work.  :P
<ogra_> indeed, if you have to much spare time :)
<ppisati> GrueMaster: if you are overloaded, and want to throw som stuff to me
<ppisati> GrueMaster: feel free
<ppisati> GrueMaster: just drop me an email and a pointer on what i've to do
<ogra_> ppisati, make kvm work and GrueMaster will be happy
<ppisati> uhm
<ppisati> does it support arm at all;?
<ogra_> then he doesnt need to wreite the world from scratch
<ogra_> no
<ppisati> ah ok :)
<ogra_> but all out automated test tools use kvm
<ogra_> and kvm only
<ppisati> A slightly modified Linux 2.6.27 and 2.6.29 kernel runs on a KVM patched kernel compiled for ARMv6 and ARMv7.
<ppisati> There is a complicated bug that manifests itself in the user space part of the elf format init code, which prevents us from running
<ppisati>  /init
<ppisati> the secondo note doesn't sound good :)
<ppisati> http://wiki.ncl.cs.columbia.edu/wiki/KVMARM:MainPage
<ogra_> yeah, i wouldnt even dare to try
<ppisati> yep
<axle> I use ubuntu 10.10 from usb flash drive on my pandaboard, and somehow update-initramfs only works as "update-initramfs -u -b /media/boot" where /media/boot is the mountpoint of my boot partition on the SD card. this makes "dpkg --configure -a" fail in some way, it "cannot find mtd partition 'Kernel'". I guess I have to set some var, any idea how to fix it?
<axle> hi btw :D
<GrueMaster> axle: Do you have an /etc/flash-kernel.conf that has UBOOT_PART=/dev/mmcblk0p1?
<axle> uhm, no. should I? I'm creating one now. anything else that should be in there?
<ps2chiper> http://d01.megashares.com/dl/6944bb4/AML8726-M_QRM%20V1.3%2020110620_clean.pdf
<ps2chiper> does anyone know if the amlogic 8726 soc can support ubuntu
<axle> aw GrueMaster I love you :) your hint and the installation of uboot-mkimage did the trick :)
<GrueMaster> ps2chiper: It appears to be Arm Cortex A9 compatible.  If you can get a kernel for it, Ubuntu software will work.
<ps2chiper> well they have openlinux.amlogic.com
<ps2chiper> i was told that android kernels wont work
<ps2chiper> i need to go to sleep now. thank you for your time
<GrueMaster> No problem.
<prpplague> ps2chiper: i think ds2 has been working on that
<prpplague> let me ask him
#ubuntu-arm 2011-09-07
<doko> rsalveti, janimo, ogra_ : bug 791256 ... somebody needs to attach all the object files and libs, like in bug 641126
<ubot2`> Launchpad bug 791256 in binutils "qt4-x11 version 4:4.7.3-1ubuntu1 failed to build on armel: assertion fail ../../bfd/elf32-arm.c:12008" [Undecided,New] https://launchpad.net/bugs/791256
<ubot2`> Launchpad bug 641126 in insighttoolkit "unresolvable R_ARM_THM_CALL relocation" [High,Confirmed] https://launchpad.net/bugs/641126
<MrCurious_> anyone know if raspberry Pi is arm8 or arm9?
<GrueMaster> Very odd.  I am trying to update an SD on a panda that uses a usb drive for root (so mmcblk0 is not mounted), yet the system has issues when I swap SD cards.  Inserting a different SD gives me a "can't read superblock" error.
<GrueMaster> dmesg is full of "error - 110" messages.
<GrueMaster> partprobe fails as well.
<ogra_> GrueMaster, i would guess it was still mounted at removal
<GrueMaster> No, it isn't.
<ogra_> not now, no
<GrueMaster> I have been hitting this for a little while, thinking the same thing.  I have checked and rechecked.
<ogra_> if flash-kernel was just fiddling with it or if there was a dangling mount that could happen
<GrueMaster> For some reason, the kernel isn't updating the partition table cache.
<ogra_> i think we had an open bug about dangling mounts in flash-kernel
<GrueMaster> I have tried it on a system that was sitting idle for over the weekend, after making sure SD wasn't mounted.
<GrueMaster> It is not a flash-kernel issue.
<ogra_> try blockdev
<ogra_> blockdev --rereadpt
<ogra_> that operates closer to the kernel afaik
<ogra_> alternatively you should be able to unbind the device
<ogra_> thats like a forced SW unplug
<GrueMaster> Nope, just tried.  I/O error.
<GrueMaster> Not really sure if it is a kernel bug or a u-boot bug.
<GrueMaster> As I see the same issue when doing netinstall over PXE boot (only using MLO/U-boot.bin on SD.
<GrueMaster> And I can not figure out how to get iscsi rootfs to work.  That was the main purpose of this exercise.
#ubuntu-arm 2011-09-08
<zma> Hi, are there prebuild Ubuntu Core images available? Or is it feasible choice to just "install it" ?
<ogra_> ubuntu core is only a rootfs tarball
<zma> ok, so it comes down to boot mechanism and drivers
<zma> Actually, I just need some alternative to Angstrom on Panda board. I don't need all unnecessary graphical environment stuff
<zma> Is Ubuntu Core a good choice to look at?
<ogra_> ubuntu-core is something for people wanting a base to create new images and want to take the effort to implement the HW related bits themselves
<ogra_> if you want a non graphical install i would go with the server image instead
<zma> good point
 * ogra_ reboots for an ac100 test install bbl
<ogra_> grrr
 * ogra_ wonders why the ac100 installer doesnt boot
 * ogra_ grumbles deeply 
 * ogra_ wonders why he gets uncompression errors with the installer initrd 
<ogra_> bug 806751
<ubot2`> Launchpad bug 806751 in debian-installer "Boot partition on SD is too small on omap/omap4" [Medium,New] https://launchpad.net/bugs/806751
<rbasak> ogra_, GrueMaster: so we were talking about what I might be able to do to help with ARM server. So that I'm clear, am I right in understanding that there's nothing apart from QA left to be done? And for QA, I'll just take items from GrueMaster's work list?
<ogra_> well, generally the apps just work regardless what arch they run on, so our main issue is QA to actually find the ones that misbehave based on the arch difference
<GrueMaster> rbasak: A lot has been tested, and the status "should" be on https://wiki.ubuntu.com/ARM/QA/Server, especially the failing tests.
<GrueMaster> One of the issues I keep running into is that there doesn't appear to be any test tools/documents/methodologies for most of my work items.  So I have to make it up as I go.
<GrueMaster> And some of the tests we do have are woefully inadequate.
<rbasak> OK so those are what you've written up below?
<GrueMaster> Yes.
<rbasak> And the items on the wiki page are what you've done so far, so don't include work items you've not looked at yet?
<GrueMaster> I have been trying to document the steps I took to start the tests so that I have something to refer to when I go back to automate them.
<rbasak> ...and all the testing you've been doing so far is on the pandaboard?
<GrueMaster> Yes.  If it isn't tested, it isn't on the wiki.
<GrueMaster> Yes.
<rbasak> OK
<rbasak> Is there an item that is nicely separated that you can give me to get started on?
<ogra_> rbasak, http://status.ubuntu.com/ubuntu-oneiric/canonical-arm.html has all workitems for the canonical-arm team
<rbasak> Note that I've only just had the pandaboard arrive in the post today, I've not tried it yet
<GrueMaster> fyi, running a raid5 on USB Sata drives from a cell phone based system is...interesting.
 * ogra_ wonders why ubuntu-arm isnt there, i thought it was added
<ogra_> if syou want to help with any of these, thast indeed appreciated
<rbasak> ...so I'll need some help to get started I expect
<ogra_> GrueMaster, hehm i did something similar with my nslu2
<rbasak> the trouble I have with the work items is that I see an entry but have very little idea on what's actually involved in doing it, so i don't know what I should start with
<GrueMaster> Well, you can either start with a preinstalled image on SD or (for better performance) use a USB drive.
<ogra_> 5 identical USB keys on a HUB set up as software raid
<ogra_> sadly the nlsu CPU couldnt cope :)
<rbasak> USB drive as in hard drive or flash stick?
<ogra_> stick
<GrueMaster> rbasak: I have no idea either.  Hence the research I have to do for each work item.
<ogra_> just for laughs ...
<GrueMaster> I have USB Sata drives.
<rbasak> GrueMaster: OK so would it be better for me to try and fix a failed test in the wiki?
<ogra_> well, even the stick speed improves
<GrueMaster> rbasak: Other than some of the PTS tests, the only ones that failed are iSCSI and IPSec.  iSCSI is arch independent at this point.
<GrueMaster> IPSec required a new kernel config, which is now in place.
<rbasak> what's pts?
<GrueMaster> Phoronix-Test-Suite.
<rbasak> ok
<GrueMaster> The clusterFS tests I will have to do, as I have the HW for it (6 pandas with USB SATA drives).
<GrueMaster> rbasak: The other test that I am blocked on is the IPv6 stuff.  The only validation testsuite I know of is from http://tahi.org, but it is BSD only.
<GrueMaster> So, open workitems that can be taken are:  SELinux, ensemble, OpenStack/LXC, and LUKS (although I thought I had tested LUKS a while ago - Alpha 3 timeframe).
<GrueMaster> Oh, that was encryptfs.  Not sure if there is a difference.
<rbasak> OK, I know my way around LUKS (I even ported it to Android) so that might be an appropriate one to take
<GrueMaster> Cool.
<rbasak> So am I right in thinking that there's no other real guidance - I just need to come up with a process that tests LUKS effectively, write up what it is, and make sure it works?
<GrueMaster> Pretty much.
<rbasak> OK!
<rbasak> What's the timescale?
<GrueMaster> Beta 2 release.
<GrueMaster> (two weeks).
<rbasak> OK and is that tested in two weeks or tested and fixed in two weeks?
<GrueMaster> Tested (and bugs filed appropriately).
<GrueMaster> This is mainly a pipe cleaning exercise, to see what needs fixing in armel server.
<GrueMaster> (of course, if the bug can be fixed quickly, great).
<rbasak> OK, I'll have to see how I get on and I'll keep you updated. I haven't even booted the board yet, so I really have no idea how long it'll take me
<rbasak> (and I need to order a PSU!)
<GrueMaster> Ping me if you need help.  I have a lot of time on these boards now.
<GrueMaster> If you have a USB Y cable, you can use it for now.  Draw power from your PC.
<GrueMaster> Just plug it into the gaget port.
<GrueMaster> *gadget
<rbasak> I only have straight cables
<GrueMaster> Should give you enough to boot the server image from SD and have networking.
<rbasak> OK
<GrueMaster> And if you do use an external USB drive, it will need it's own power source.
<rbasak> I have a USB caddy that takes its own power so that should be OK
<GrueMaster> Excellent.
<rbasak> Where do I get the image? Will the latest in cdimage be OK?
<GrueMaster> Yes, that should work  well for just running off SD.
<rbasak> So I just dd it straight on?
<rbasak> I can borrow an SD card out of my camera for now but I'll need to order one for longer term. What's the recommended size?
<GrueMaster> pretty much.  The image is an img.gz file, so gunzip < <image> |dd bs=4M of=/dev/mmcblk0 (or whatever the SD is on your pc).
<rbasak> OK
<GrueMaster> I use 8G for my server testing, but anything from 4G up will do.
<GrueMaster> For preinstalled images.
<GrueMaster> If you do netboot, you only need ~30-50M on the SD.
<GrueMaster> And the rootfs can live on the USB drive (~10x faster).
<GrueMaster> brb
<CocoaGeek> hello
<rbasak> OK PSU and SD card ordered but I think I have enough to get going for now
<CocoaGeek> can I just use arm-linux-gnueabi-g++-4.4 on x64 Ubuntu 11.04 to cross-compile for Ubuntu running on a OMAP4 netbook?
<dcordes> rsalveti: hey
<GrueMaster> CocoaGeek: It should work.  For cross-compile issues, you may want to ask in #linaro though.  They are actively working on that stuff.
<CocoaGeek> GrueMaster: Thank you
<dcordes> I am wondering why fennec does not appear in the oneiric version  http://packages.ubuntu.com/en/oneiric/fennec
<dcordes> so I emailed the package maintainer but I do not receive any reply
<dcordes> where should such things be discussed ?
<rsalveti> dcordes: hey!
<rsalveti> dcordes: true: https://launchpad.net/ubuntu/+source/fennec
<rsalveti> ubuntu-dev probably
<dcordes> rsalveti: can't your put your foot down ? :D you told me you see use for it on tablets etc.
<ppisati> GrueMaster: saw the beagle xm network stuff
<ppisati> GrueMaster: i'm at plumbers, i'll take a look at it next week
<GrueMaster> ppisati: I believe it is u-boot related.
<ppisati> GrueMaster: yep
<ppisati> GrueMaster: is the new u-boot the pxe-enabled one?
<GrueMaster> Not sure.
<GrueMaster> I don't think so.
<ppisati> ok
<ppisati> anyway, when i'm back i'll take a look
<ppisati> GrueMaster: thanks for the debug
<ppisati> GrueMaster: and btw, since it seems you are really work-overloaded
<GrueMaster> To be honest, I haven't had time to really look at it.
<GrueMaster> (beyond what is in the bug report).
<ppisati> GrueMaster: if there's something i can do, i mean, feel free to throw it to me :)
<GrueMaster> Ok.
<ppisati> oooooooook :)
#ubuntu-arm 2011-09-09
<twb> lilstevie: I bought a TF101 (yaaaay!)  Should I update to the latest android firmware before attempting to switch it to debian?
<lilstevie> twb: probably not :p you will end up blowing away everything on the fs and need to redo that stuff anyway
<twb> $coworker said he thought it might have important fixes for the keyboard part or something
<twb> (He bought a 16G one from RUC a few months ago, and followed your stuff to put Ubuntu on it last week.)
<lilstevie> well are you going pure linux, or dualboot
<twb> I don't care about android
<lilstevie> cause things like prime include dock firmware updates
<twb> Yeah, I think he is running prime
<lilstevie> to be honest dock firmware updates really are to benefit android
<twb> I mean MAYBE it'd be useful to not blow away android on day one, but I kinda doubt I'll ever use it
<twb> It's not like I ever used windows or vxworks on my netbooks and routers
 * twb thinks -- I probably shouldn't be drinking either
<lilstevie> heh, I don't have android on my device
<twb> Good man
<twb> Bleh, I forgot I have to get pppd working with this 3G dongle before I'm allowed to play with my transformer
<lilstevie> lol
<soren> I have a Pandaboard rev A3. http://www.omappedia.org/wiki/Prebuilt_ubuntu_binaries only mentions up to A2. What to do?
<lilstevie> soren: it doesn't really matter
<soren> Ok.
<lilstevie> soren: https://wiki.ubuntu.com/ARM/OmapNetbook only has one image
<lilstevie> and the only difference between the A2 and A3 is the CPU has been updated for ES2.2
<soren> I'm installing the headless image on an SD card right now. I don't have a serial cable handy. I don't suppose that image comes with any sort of networked access (ssh or even telnet)?
<lilstevie> that I don't know I don't have a panda, nor have I used the headless image before
<soren> Ok.
<twb> OK, got the 3g doodad working, back to transformer
 * twb digs up pile of napkins from last week when we were talking about this
<twb> OK, so step #1 of flashing it is to find a copy of the nvflash ELF binary that can be trusted, i.e. download it myself from nvidia.com rather than "some forum post"
<twb> Is that achievable?  AIUI it's only available bundled in their dev board SDK, but I'm happy to download 200MB of zip file to get a trusted version of that one binary.
<lilstevie> twb: it is in the L4T pack
<lilstevie> which isn't that big
<twb> Do you have the exact URL on you?
<twb> Otherwise I'll wade through their search page
<twb> FFS, all the ddg.gg hits are 404d
<lilstevie> http://tegradeveloper.nvidia.com/content/linux-tegra-release-12-alpha-1-released
<twb> ty
<lilstevie> driver package has nvflash binary
<twb> Man, 10MB, why do all these forum weenies keep reposting it
<twb> It's like those bt users who put a bunch of .rar's in another rar
<ogra_> there is a deb of that driver (not sure it will work on your kernel thrugh)
<ogra_> https://launchpad.net/~ac100/+archive/ppa
<twb> Well, eventually I'd like to run stock Debian armhf kernel with as few device-specific patches as possible, but for now I was just going to git clone lilstevie's tegralinux one and compile that
<lilstevie> twb: well I begrudgingly package it, if I didn't I would have a bunch of people continually complaining that my pack doesn't work
<lilstevie> twb: which one, my repo has 2 :)
<lilstevie> one is L4T driver compatible but only works with u-boot
<twb> Dunno, I was gonna ask you once I was confident I had nvflash working and metastrap was chugging away building a btrfs debian sid armhf rootfs :P
<twb> Oh, I can replace the bootloader with uboot?
 * twb like uboot
<lilstevie> yes, but u-boot is in its infancy
<twb> Meaning that it isn't production-ready for this device?
<lilstevie> it is missing some stuff :p
<twb> I mean, I'd like to minimize my use of non-free software, but at the same time I don't want to brick it or not be able to e.g. use the screen
<lilstevie> APX is always there
<twb> That's the stage 1 bootloader?
<lilstevie> bootrom
<lilstevie> stage0
<twb> OK
<twb> It would be nice if I could interactively pick which kernel to boot and whether to pass "single" to it, but I'm assuming that's... nontrivial at the moment.
<lilstevie> well you could do that with the standard bootloader
<twb> Oh, OK.  I thought that only had two options "normal boot" and "recovery boot"
<lilstevie> by adding single to the recovery kernel :p
<twb> Yeah, that's plan B
<twb> two kernels plus single vs. no single means four cases not two :P
<lilstevie> if we can get the GPIO driver to co-operate with u-boot it would be trivial
<lilstevie> but at the moment it is non-functional
<twb> OK
<twb> That ac100 PPA has a main and restricted in pool/, but only a main in dists/.
<lilstevie> ogra_: doing 'dhclient -r;dhclient wlan0' seems to add the route, RE: network manager not setting the default route for me in oneiric
<ogra_> weird
<ogra_> did you file an NM bug ?
<lilstevie> not yet
<lilstevie> was about to do that, only hit me today to try renew the lease
<lilstevie> renewing*
<ogra_> twb, go to the package details,. thats a launchpad bug (the package has "restricted" in the control file, LP doesnt really have a concept for restricted packages)
<twb> OK
<twb> was just mentioning it fyi
<ogra_> yeah, its known :(
<ogra_> for the P release we will hopefully have the driver in the actual archive :(
<ogra_> err
<ogra_> :)
<twb> lilstevie: awesome, that version of nvflash is 1) statically linked; and 2) has --help.  Much nicer than "doesn't run at all" old version from <wherever> that I was looking at last time
<twb> (static linking = works without a 32-bit userland)
<lilstevie> twb: hmm, well the one in my package is from that dump
<lilstevie> the other one floating around is the asus one
<twb> OK, this is weird
<twb> I connect the keyboard (dock) 40-pin connector to my laptop, and lsusb can see two devices on it -- both ASUS vendor USB ID, one is a broadcom bluetooth device
<lilstevie> interesting
<twb> Ah, nm
<twb> the bluetooth is just the onboard bluetooth in my netbook
<twb> Gods, that 40pin cable is flimsy
<twb> OK, why isn't this working?
<twb> http://paste.debian.net/128994/
<twb> Running nvflash as root seems like the coward's way out; I'd rather just have udev make the tf world-writable or so.
<ogra_> i think nvflash uses raw device access, you need root
<twb> Surely if I have write access to /dev/foo, that is "raw device access"
<twb> The only related superuser capability I can see is CAP_SYS_RAWIO
<twb> And that looks to be for something else
<ogra_> well, i havent seen anyone getting nvflash to work without root in the 1.5 years i work with nvflash :)
<ogra_> if yuo find a way, tell me :)
<twb> OK, I did this
<twb> chgrp -Rh twb /dev/bus/usb/*
<twb> Now I get a different error
<twb> USB device not found255
<ogra_> intresting
<twb> Maybe I need to plug the 40pin into the table directly instead of the dock?
 * ogra_ never had to modify anything to flash his ac100
<twb> btw same error running it as root
<ogra_> plugging and running nvflash just works
<twb> ogra_: running as root I bet tho
<ogra_> indeed
<twb> I try to be a bit paranoid :P
<ogra_> i only use nvflash for new ac100's anyway though
<ogra_> after the first flashing i can flash from userspace
<twb> yeah openwrt is like that too
<twb> lilstevie: do I need to do something special to put the TF into guest most?
<twb> *mode
<twb> hmm, there is some little "asus sync" thing on the tf's screen
<twb> ANd another "usb debugging connected"
<twb> Grmph, I'm not having any joy getting nvflash to see it
<twb> Maybe I should read the docs more than just --help
<twb> Hmm, gentoo's tegra2 page says "To power on the board, you need to press *BOTH* the Force Recovery and the Power on buttons until the LEDs power up. Then execute the following command to flash the bootloader."
<twb> OK, booting while holding the volume down gives "safe mode"
<lilstevie> ok back
<lilstevie> sorry disconnected for a sec
<twb> lilstevie: short version: I'm trying to make "./nvflash --getbct" do something useful
<lilstevie> you should get error 0x4 if you invoke nvflash like that :p
<twb> Hum
<lilstevie> yeah you cant
<lilstevie> the tf is an SBK locked device
<lilstevie> you need to use the --sbk option
<lilstevie> and with that you also need to specify --bl --bct and --config
<twb> lilstevie: first of all, do I need to do anything on the TF to put it into "upgrade mode" or anything?
<lilstevie> vol up plus power on boot will put it in APX
<twb> OK
<twb> And I need to do that?
<lilstevie> need to do which?
<lilstevie> put the tablet in APX?
<twb> Do I need to put it into APX mode to use nvflash
<lilstevie> yes
<twb> OK.
<lilstevie> nvflash is for communicating with apx
<twb> goddammit, now it isn't turning on at all
<twb> ok here we go
<twb> It seems like from off I can't just hold both vol+ and power and have it boot
<twb> Do i get any visual feedback when it goes into APX?
<twb> Aha
<twb> Answer is no, the screen is off, but lsusb suddenly sees an nvidia device
<twb> Progress
<twb> ogra_: you can use nvflash as non-root user provided you have write access to the block device.
<ogra_> which you usually dont :)
<twb> ogra_: but what this means is that you wrie a udev rule to say something like GROUP=disk
<ogra_> eeek
<twb> Then instead of running it as root, you run it as a non-root user who is in the disk group
<ogra_> thats more of a security hole than using root
<twb> Yes, well, you know what I mean.
<ogra_> the disk group should never be used for users
<twb> If you want use polkit or something to hand it to the user on the local screen or whatever
 * ogra_ -> off for a phone conf
<twb> np
<lilstevie> later ogra_
<twb> lsusb can't see it anymore after doing that bct (which did finally fail with error 4)
<lilstevie> yep that is cause of SBK
<lilstevie> error 0x4 is when the command is invalid
<twb> Does it quit APX on the first command, or the first bad command?
<lilstevie> which in the case of these SBK locked devices that means the command is incorrectly encrypted
<lilstevie> it shuts down USB communication, only on incorrect bootrom commands
<twb> OK
<lilstevie> but when you use an SBK locked device you need to upload the miniloader (built in to nvflash) and bootloader to get interactive
<lilstevie> at which point commands are no longer encrypted anyway
<twb> OK, the SBK in your forum post (ending in 98) works for me, yay.
<lilstevie> awesome :D
<twb> So now I have a working nvflash I need to learn how to use it.
<twb> First goal is to make a complete dump of all the data on there to begin with, just in case I ever want to put it back
<lilstevie> ok, well best thing is to pass it create, and just configure the flash config
<lilstevie> ok ./nvflash -r --download <partition ID> <filename>
<twb> Shouldn't I get the partition table first? :-)  I don't know /a priori/ what partition IDs there are
<lilstevie> well you could do that :p
<lilstevie> but why reinvent the wheel
<lilstevie> http://androidroot.mobi/2011/06/13/nvflash-on-asus-transformer/
<twb> Because I trust a dump I make myself more than "what some guy told me"
<twb> Same reason I wanted to get nvflash direct from nvidia.com
<twb> (No offense intended, I'm just a paranoid sysadmin.)
<lilstevie> nono I mean for flash.cfg and bct
<twb> So presumably you can't just say "nvflash, please fetch flash.cfg and bct from my device, and write it to a file" ?
<lilstevie> no
<lilstevie> what you get is a basic information
<twb> OK, then I fall back to plan B, which is using the prepared version you linked to :-)
<lilstevie> which you then need to work on
<lilstevie> and bct is something that is not really easy to get :p
<lilstevie> on device it is encrypted
<twb> Yeah but symmetrically -- you have the shared secret :-P
<lilstevie> yeah
<lilstevie> :p
<twb> Also this is the 32GB version -- does that matter?
<lilstevie> no
<twb> Phew
<lilstevie> flash.cfg is universal
<twb> Does it matter for bct?
<lilstevie> the 0x808 partition ID fills to end of partition
<twb> OK, awesome
<lilstevie> and no bct is config data for the tegra2 cpu not the emmc controller
<twb> Ooooh right
<lilstevie> and er, partition attribute to end of flash*
<twb> I am used to in uboot sheevaplug where IIRC your "partition table" is basically half a dozen disk offsets and to boot you say "jump to block XXX of the MTD and start executing whatever you find there"
<twb> I thought bct was that stuff
<lilstevie> ah
<twb> afk getting caffeine
<twb> thanks for all your help btw
<lilstevie> on sheeva bct is in the SPI IIRC
<lilstevie> cya
<twb> back
<lilstevie> heh that was quick :p
<twb> got a coffee machine in the office
<lilstevie> ah
<twb> Ah, OK, I got bct mixed up with these .cfg files in your linux-flash-kit.tar.gz
<lilstevie> yeah the cfg files are the partition
<twb> Is flash/default.cfg the flash.cfg that matches a brand new tf?
<lilstevie> yes
<twb> You know, it just occurred to me that if nvflash wants to write to a file instead of stdout, I won't have space to write it on my netbook
<twb> I was planning more like dd if=/dev/sda1 | gzip >sda1.orig.gz
<lilstevie> nvflash normally writes out to stdout
<twb> Cool
<lilstevie> oh wait you mean for the backups?
<twb> Yeah
<twb> e.g. --getbct wants me to provide --bct-file or so
<lilstevie> the partition with UDA is the emmc
<twb> OK
<lilstevie> well, the "emmc to android"
<lilstevie> the rest of your backup isn't that big
<twb> OK
<lilstevie> don't need to back up PT, USP
<lilstevie> PT is generated at nvflash --create
<lilstevie> USP is the "staging" partition that blobs are written to from android
<lilstevie> for OTA updates
<twb> Is android using ext3 or 4?
<lilstevie> ext4
<twb> Because default.cfg says 3, but the licenses page in android on the device, says ext4
<twb> OK
<lilstevie> it is ext3 for nvflash
<lilstevie> because nvflash doesn't know or understand the difference
<twb> Yeah, I guess nvflash doesn't distinguish.
<twb> Wish I knew what it actually did different for "ext3" vs "basic"
<twb> What lives in MSC?
<lilstevie> tags
<lilstevie> as for ext3 vs basic
<lilstevie> it writes it differently
<lilstevie> basic just does a 1:1 raw write
<lilstevie> but MSC I guess really does not need to be backed up either
<twb> Whereas ext3 only writes active blocks?
<lilstevie> something like that yeah :)
<twb> Yeah, cool.
<lilstevie> still takes a full image, but only writes the ones that have content
<twb> Even if I completely hose the UDA partition, I can still drop into APX and upload a new one, right?
<twb> Because I plan to use btrfs :-)
<lilstevie> even easier
<lilstevie> :p
<lilstevie> UDA is "User DAra"
<twb> haha
<lilstevie> so like in android, drop to CWM and do a factory reset
<lilstevie> :)
<twb> "honolabaru data-san"
<twb> CWM is the rescue partition?
<twb> Like, the rescue mode uses a completelt separate root= filesystem?
<lilstevie> CWM is Clockwork Recovery Mod
<lilstevie> android recovery doesn't use a root= perse
<lilstevie> per se*
<lilstevie> the initrd is /
<lilstevie> and things like /system get mounted atop it
<lilstevie> android doesn't pivot_root
<twb> Christ, that's... unnervin
<twb> I mean I work with some elaborate initramfs's, but nothing like android or splashtop
<lilstevie> well android has its base set of tools in the initrd as well as the init info
<lilstevie> but the android system itself gets mounted into /system
<lilstevie> I certainly don't consider it "normal"
<twb> Silly embedded devs :P
<lilstevie> heh
<lilstevie> the bootimg is really just a zImage squished up with an initrd, + a custom header with some information for the bootloader
<twb> Yeah, that's how devicevm does it for their splashtop images, too
<lilstevie> not all android devices follow that though
<lilstevie> samsung don't
<twb> When you compile the kernel you can even say "my ramdisk is that dir over there, tack it onto the end of the zimage"
<lilstevie> they use an initramfs compiled when you compile the kernel
<lilstevie> using the proper zImage packing method
<lilstevie> because they use a partition called params
<lilstevie> samsung use a u-boot based bootloader though
<twb> So: ASUS are doing it wrong, film at 11
<lilstevie> param.lfs is an j4fs filesystem with a param.blk which acts as nvram
<twb> At least it's not using a damn graphical EFI BIOS like these new x86-64 motherboards I got last week
<lilstevie> heh
<lilstevie> I'm used to EFI tbh
<lilstevie> all my computers have EFI
<lilstevie> well AppleEFI
<twb> "Sorry, we only support huge yelling bouncing icons, not text.  This way is TEH FUTURE"
<twb> I am referring to MSI ClickBIOS
<lilstevie> ew
<lilstevie> need something like rEFIt
<twb> Last time I touched Apple it was still using OpenFirmware, which I still looooove
<lilstevie> OF was win
<lilstevie> I miss OF
<twb> And POWER beats x86-64
<lilstevie> hands down
<lilstevie> thats why my file server is an xbox360 :p
<twb> I'm not happy about ARM's royalty model either, but they've pretty much won the embedded space
<lilstevie> using the JTAG hack ofc
<lilstevie> ARM may have a shoddy royalty model, but their processors are win in the embedded space
<twb> Yep
<lilstevie> I couldn't imagine going back to MIPS or the likes
<twb> Although I think they should probably ditch thumb and jazelle and stuff and just bake one ISA into any given core
<lilstevie> thumb does have its benefits
<twb> lilstevie: Forth is best for microcontrollers tho
<twb> REPL FTW
<twb> You said MSC is for tags -- what are tags?
<lilstevie> well like bootloader args
<lilstevie> kinda what I was trying to say, but a bit more complex
<lilstevie> they also serve as tags for telling recovery to do certain actions
<lilstevie> most common use though is a file called recovery tells the bootloader to boot straight into recovery
<twb> Oh, OK
<twb> So kinda like a combination of nvram, syslinux.cfg and /forcefsck
<lilstevie> kinda'
<lilstevie> just done very wrong
<twb> Heh
<lilstevie> I hate the bootloader
<twb> One day
<twb> One day we will have coreboot on the PROM
<lilstevie> I'd love to see UEFI :p
<twb> And it will not load seabios or refit, it will load the openfirmware implementation that sun dumped into coreboot just before oracle ate them.
<lilstevie> heh
<twb> EFI... saying "DOS 6 like UI!" as if that's a good thing
<lilstevie> :p
<twb> And it is, man, it even has commands like "dir"
<twb> And you run "if" at the prompt and it says "error: only works in batch scripts"
<lilstevie> heh
<twb> Ruh roh
<twb> ./nvflash --read UDA /dev/stdout  --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 | file - # <-- hung
<lilstevie> ok have you already uploaded the bl and stuff?
<twb> Nope
<lilstevie> also by ID I mean the numerical ID
<lilstevie> you need to put it into bootloader update mode
<lilstevie> apx wont listen to many commands when an SBK is set
<twb> Do I do that with ./nvflash --bl --sbk ...; and then it's in bootloader update mode until next reboot?
<twb> Ah, I need a bootloader.bin?
<lilstevie> yes
<lilstevie> and you also need a bct
<twb> I notice the bootloader.bin you supply doesn't match any of the ones in tegra-linux-12.alpha.1.0
<lilstevie> no
<lilstevie> it is an asus one
<twb> Hum.  Can I d/l that from foo.asus.com? :-)
<lilstevie> yes
<lilstevie> in the dlupdate you need to extract a file called "blob"
<twb> Got the URL handy?
<lilstevie> no sorry
<twb> Is it the stuff labelled "firmware", like 200MB dl file?
<lilstevie> yep
<twb> OK
<twb> Damn page needs js, and isn't working even in my fallback js-capable browser :-/
<lilstevie> :/
<twb> OK, reverse-engineered their js
<lilstevie> heh
<twb> It's EeePAD/TF101/UpdateLauncher_US_epaduser8659.zip, just need the hostname...
<twb> Which is in http://support.asus.com/js/Download.js
<twb> Bam: http://dlcdnet.asus.com/pub/ASUS/EeePAD/TF101/UpdateLauncher_US_epaduser8659.zip
 * twb closes Xorg again
<twb> lilstevie: FYI, the md5sum of blob also doesn't match yours
<lilstevie> ?
<lilstevie> oh right you are doing an md5 of the entire blob
<lilstevie> :p
 * twb sighs
<twb> Lemem guess another yak to shave
<lilstevie> that blob is 4 or 5 partitions worth od data
<lilstevie> of*
<twb> Oh, stupid me, the blob is the whole thing
<lilstevie> https://github.com/AndroidRoot/BlobTools
<lilstevie> not the whole thing
<twb> Gotcha
<lilstevie> but it is the partitions EBT(bootloader) PT(tegraparts pt) SOS(recovery kernel) LNX(normal boot kernel) at minimum
<lilstevie> also there are multiple versions of the bootloader
<lilstevie> so md5 may not match
<lilstevie> there are at least 7 versions
<twb> I might as well use the latest one from that blob tho, right?
<lilstevie> but only 3 are visually noticeable
<lilstevie> yeah, well, doesn't really matter :p
<lilstevie> only thing with the newest is that to boot from root=/dev/mmcblk1p* you need to add a rootwait
<twb> Hum
<lilstevie> that is the microsd
<twb> Oh, no, I only care about booting from eMMC
<lilstevie> yeah :p
<twb> Except if I completely brick it, in which case SD isn't gonna work either
<lilstevie> you can't completely brick :)
<lilstevie> APX is always there
<twb> k
<twb> Apparently OMAP on the ROM has enough smarts to boot off a FAT16 SD card, no matter what
<twb> Which is pretty nice, even if you have to carefully align the CHS and shite
<twb> *Apparently on OMAP boards the ROM
<lilstevie> tegra2 does too
<lilstevie> well,
<lilstevie> tegra2 can change boot devices
<lilstevie> but in our case the reason it drops back to APX is because the tegra2 only has the eMMC configured as a boot device
<twb> OK, so which blobunpack result is bootloader.bin ?
<lilstevie> blob.EBT
<twb> Ha, so it's not an AmigaOS bitmap font :P
<lilstevie> they are named for the partition code
<lilstevie> so EBT refers to EBT in the flash.cfg
<twb> Nod
<twb> OK, so now I have a bootloader.bin that I can trace back to asus.com, and a bct from "some guy", and I need to load these in using -bl
<lilstevie> twb: not really "some guy" :p the guy who gave the tf root, and who got the sbk for nvflash in the first place :p
<lilstevie> doubting the bct is as good as doubting the sbk :p
<lilstevie> look at the command line given in the scripts from the androidroot pack
<lilstevie> remove --create and --go
<lilstevie> and add --sync
<lilstevie> that will get you into interactive mode
<lilstevie> -r is required for each command
<lilstevie> after the sync that is
<lilstevie> as it is resume
<twb> I know what you mean, but I see a difference between a hash and a blob
<lilstevie> and --download reads the partition
<lilstevie> twb: unfortunantly you hit a chicken and egg situation
<lilstevie> you can't extract the bct without first uploading one
<twb> Yeah, I realize that
<twb> Er, no I didn't realize *that*, but oK
<lilstevie> it is based off the asus service center one
<lilstevie> but regenerated
<lilstevie> using cros bct tools
<twb> Is -r the same as --read ?
<lilstevie> no
<twb> Oh resume
<lilstevie> -r is resume
<twb> My brain hurts
<lilstevie> nvflash is a bitch
<twb> Hang on surely for backing up the original partitions I want --read not --download
<lilstevie> and sorry made a mistake up there :p
<lilstevie> yes
<lilstevie> that is the mistake :p
<lilstevie> I'm so used to uploading I automagically went for it :p
<twb> So ./nvflash --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --bl bootloader.bin --bct transformer.bct --sync -r --read 6 orig.vmlinuz
<twb> That will backup the original LNX partition?
<twb> (I figure I should test with the small partition first, not UDA)
<lilstevie> you need --setbct in there
<lilstevie> and not the -r --read 6 orig.vmlinuz
<lilstevie> the -r --read comes after the first command
<twb> So the order of the arguments matters?
<lilstevie> well it is more that they are seperate commands
<lilstevie> sync throws it into "phone update mode" from the bootloader
<twb> OK hang on, separate commands within a single invocation of nvflash, or separate invocations of nvflash?
<lilstevie> then once it is in that mode, ./nvflash -r --read 6 boot.img
<lilstevie> seperate invocations of nvflash
<twb> OK
<twb> ./nvflash --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --bl bootloader.bin --bct transformer.bct --sync --setbct
<twb> ^^ that's just sitting there
<lilstevie> hmm
<lilstevie> order probably matters
<twb> And dmesg just whinged because nvflash has been in D state for 2 min :P
<twb> I can fix that by just replugging the USB, tho
<lilstevie> and rebooting the tablet
<twb> That's plan B
 * twb does that now
<lilstevie> you will need to reboot the tablet anyway
<lilstevie> ./nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync
<lilstevie> that should be the command
<lilstevie> nvflash is really badly coded
<twb> Thanks
<twb> What's the odmdata for
<lilstevie> odmdata is mode device specific configs
<lilstevie> sets how much ram, and video output et al
<lilstevie> it is a standard odmdata though
<twb> As in settings baked into the nvflash binary?
<twb> oh ok
<lilstevie> flags for the processor
<twb> Woo
<twb> I got something on the screen
<lilstevie> :)
<twb> "!!!!!!device update sucesss!!!!!!!"
<twb> Obviously the ASUS engineers are pretty excitable
<lilstevie> nvidia engineers*
<twb> k
<lilstevie> :p
<twb> So once I have done that BCT/BL upload, I just say "./nvflash -r 6 orig.vmlinuz" ?  I don't need any of the SBK and stuff until the next reboot?
<lilstevie> -r --read and yeah
<lilstevie> also it isnt really a vmlinuz :p
<twb> orig.zImage then?
<lilstevie> boot.img
<lilstevie> :p
<twb> Righto
<twb> Is that the combined header/kernel/ramdisk thing that abootimg generates?
<twb> Someone should teach libmagic to recognize it.
<phh> what about you N
<phh> ?*
<twb> phh: sorry, are you talking to me?
<twb> OK, I pissed it off
<twb> Just to see what would happen I tried a named --read, and now it doesn't want to -r
 * twb reboots TF
<twb> lilstevie: how come you said to backup UDA, when the one in default.cfg with a filename is APP ?
<twb> Presumably APP is the OS, and UDA is initially an empty ext4
<lilstevie> I said you shouldn't need to back up UDA :p
<twb> Oh I misread then
<lilstevie> but make sure you back up BAK
 * twb thinks: if there's already an immutable OS (APP) and a mutable user data (UDA) partition, instead of a single unified btrfs filesystem, I could/should use debian live to make a squashfs APP, and use aufs to merge that with a mutable btrfs UDA
<twb> Same as I would for a live USB key
<twb> And then when upgrading, I upload the new test squashfs to SOS, and if it works, I use that until the next upgrade, when I upload to APP again, and go on flip-flopping between the two
<twb> I rolled out that approach (except with ext instead of btrfs) for a kiosk in a retirement village, it was pretty robust
<twb> Oh, and "restore factory defaults" is just to use a tmpfs instead of btrfs in the union :-)
<twb> lilstevie: what kernel version is your git tree at?  .39?
<twb> about .38 (IIRC) or better will mean I can use XZ compression for the squashfs, which is like 40% better than gzip
<lilstevie> .38 for u-boot
<lilstevie> .36 for standard bootloader
<twb> Hrm
 * twb checks when SQUASHFS_COMP_XZ hit
<lilstevie> also no aufs
<twb> Oh yeah, damn.  I remember now aufs all the union filesystems are out-of-tree
<twb> Can I tell nvflash not to flood my I/O bus printing "\ 228249600/536870912 bytes received" as fast as it can?
<lilstevie> no
<twb> Balls
<twb> Maybe I can at least 2>/dev/null
<lilstevie> under a "normal" shell it updates over the top of itself :p
<lilstevie> yeah probably
<twb> Yes but it's doing so so fast, and screen can't keep up
<twb> It would probably be fine running directly in fbcon but not in screen
<lilstevie> heh
<twb> yeah 2>/dev/null is fine
<twb> I wish val aurora had time to get "proper" union mounts into mainline
<twb> 2>/dev/null isn't working, either ^C'ing the previous run pissed it off, or it can't handle 2>/dev/null
<twb> I'll try running outside of screen
<twb> Yeah that's much faster, it's done 100MB in a few seconds
<twb> Aaaand now it's stopped because the netbook's SSD's buffer is full :P
<lilstevie> lol
<twb> netbook is running btrfs w/ block-level gzip compression, on an ssd
<twb> I/O is not its fortÃ©
<twb> (-tbtrfs -ocompress=lzo wasn't available when I set it up)
<twb> WOW, nice, e2fsck on the APP partition says 0.0% fragmented
<twb> Which is why resize2fs -M finished in O(1) time
<lilstevie> well it is only marked ro
<twb> Yeah but it means they did a good job setting up the original filesystem.
<twb> If you just make an ext3 and loopback mount it and copy the chroot in, then do some finishing touches, it's not that well packed
<twb> Ah, so SOS is just a small rescue boot.img, not a complete second rootfs
<lilstevie> twb: mine is 0.2% fragmented by doing that
<lilstevie> yeah :p if you read that before you would have seen that :p
<twb> This probably won't interest you, but http://paste.debian.net/129033/
<lilstevie> heh, nice little comparison
<twb> lilstevie: are you in .nz?
<twb> Must be late; it's 1AM here in melbourne, and I'm going home.
<twb> Hopefully tomorrow I'll find time to actually roll a kernel and rootfs :-P
<lilstevie> I'm in melbourne :p
<twb> Ah, okies
<twb> Then I definitely will need to buy you some beers after all this
<lilstevie> just grew up in nz :)
<twb> I'm at cyber.com.au, in Burnley (basically Richmond)
<lilstevie> ah nice
<lilstevie> I'm a student at VU :p
<twb> Are you likely to be around tomorrow?
<twb> in irc I mean
<lilstevie> probably
<twb> awesome
<twb> g'night
<lilstevie> later
<RoAkSoAx> hi Guys, I was wondering if any of you have PXE booted a pandaboard lately
<RoAkSoAx> as I now keep getting an error when trying to partition
<GrueMaster> RoAkSoAx: I do it daily.  What is the issue you are seeing?
<RoAkSoAx> GrueMaster: http://me.roaksoax.com/arm.png
<GrueMaster> Sounds like a preseed issue, not a pxe issue.
<RoAkSoAx> GrueMaster: right, though I've been using the same exact preseed I was using before and I didn't have the error
<RoAkSoAx> GrueMaster: http://paste.ubuntu.com/686003/
<RoAkSoAx> GrueMaster: http://paste.ubuntu.com/686004/
<GrueMaster> Are you trying to netinstall to SD?
<RoAkSoAx> GrueMaster: yes
<GrueMaster> I don't think that works.  There are still issues with SD partitioning in partman for d-i.
<GrueMaster> (although the bug I filed keeps getting marked as invalid w/o explanation.)
<RoAkSoAx> GrueMaster: might be that, but again, I'm using the same preseed file I used before and that worked
<GrueMaster> For performance reasons, I suggest doing netinstall to USB drive (leaving SD for boot).
<RoAkSoAx> GrueMaster: the SD card has two partitions, the boot and rootfs
<RoAkSoAx> GrueMaster: yeah, I guess I'll end up doing that. Thanks
<GrueMaster> Hmm.  Not sure then.  Maybe you need to remove the root= line from your boot cmdline until after netinstall.
<RoAkSoAx> GrueMaster: did that already
<GrueMaster> I can try it later today (maybe).  All 6 of my pandas are currently tied up with CEPH cluster testing atm (which I am still trying to figure out).
<RoAkSoAx> GrueMaster: cool, If you get the chance just let me know. Thanks
<GrueMaster> Will do.
<CocoaGeek> hi
<CocoaGeek> I installed arm-linux-gnueabi-g++-4.4 on an Ubuntu 11.04 x64, but when I compile some code I get this error: invalid 'asm': invalid operand for code 'w'
<CocoaGeek> I'm guessing that maybe I'm missing some include files specific to ARM â¦
<CocoaGeek> any suggestions?
<CocoaGeek> the error is on a line that contains a call to htons()
<jhobbs> post some info about how to reproduce it on paste.ubuntu.com
<jkridner_> we are looking at doing another BeagleBoard revision (geared toward the lower end with more hardware expansion) and are debating ferociously amongst ourselves if distro vendors would care if you needed a different (incompatible) bootloader for SD card images made for this new version board.  how big of a deal would that be?
<steev_> ood5Chew
<GrueMaster> jkridner_: It would be a very big deal.  This would mean that we would have to build yet another omap image, and it would be very confusing to users.
<GrueMaster> CocoaGeek: This is a question best asked on #linaro I think.
<CocoaGeek> thanks GrueMaster
<jkridner_> GrueMaster: if the solution was to add an extra MLO-like file to the SD card image, would that be sufficient?
<GrueMaster> jkridner_: Linaro is currently building MLO from u-boot.  This would likely require a new u-boot package, plus a new image to support for our preinstalled images.
<infinity> jkridner_: Is it completely infeasible to have an MLO that works for both? :/
<jkridner_> I'm not sure as the device on the new board seems to have a different internal memory address.  I'm trying to find a work-around.
<GrueMaster> Device lookup table in MLO?  It would be cleaner.
<jkridner_> One of my challenges has been to articulate the need for having a single MLO file for both.  Most of the people I interact with to help me do board bring-up don't seem to feel it is necessary/useful.
<prpplague> jkridner_: hehe
<prpplague> jkridner_: the joys of developing in a vaccum
<infinity> Those people need to work with random community people who don't want to have to know their exact board revision to make it work.
<CocoaGeek> jhobbs: sorry, were you talking to me?
<jhobbs> yes
<jkridner_> One challenge is that the load address and start address are encoded in the MLO file.  I'm looking at possibly using an on-board I2C EEPROM to load enough code to get around this issue.
<infinity> jkridner_: We all realise that the ARM SoC world has been very used to having a new bootloader for every single SoC, board, revision, and moon phase, but I'm not sure anyone thinks that perpetuating this madness is a good idea.
<jkridner_> I'm trying to figure out if BeagleBoard can go about it differently.  It is a challenge.  I'm the one being told that I'm mad.
<jkridner_> is there a log of this conversation?  I want to share it with the bring-up team.
<prpplague> jkridner_: there are plenty of things that can be done, the problem is getting a solid acceptable solution that fits with the legacy existing beagle designs
<prpplague> jkridner_: http://irclogs.ubuntu.com/
<prpplague> jkridner_: i already did this battle for the pandaboard and some of the other omap4430 based dev platforms
<jkridner_> prpplague: what I care about is providing a reference that is backwards compatible with BeagleBoard and BeagleBoard-xM.  I can't do anything about legacy code running on newer platforms, but I can ask people to upgrade.
<jkridner_> prpplague: I'm a persistent nag who is used to getting my way. :)
<infinity> jkridner_: The bottom line for Ubuntu here is that if you hand us a new board-specific MLO, we'll happily ship it in the archive, but we won't build Yet Another OMAP image.
<prpplague> jkridner_: if you think we call you nag, maybe it is best you not know what we call you in reality.........
 * prpplague jokes with jkridner_ 
<infinity> jkridner_: So, we'll have installers for Beagle and XM, but not for this NG thing.
<infinity> jkridner_: Which, from my experience, can reall cut down on the community actually using the board.  Oddly enough, some people don't like having to sort out how to boot a system just to use it.
<GrueMaster> jkridner_: It is my understanding that MLO needs to fit in 64k.  It is currently 34k.  I think this can be accomplished with lookup tables within the same binary.
<jkridner_> infinity: but, if the new MLO worked with this NG thing *and* Beagle and XM, would you replace the MLO such that your image booted with all 3?
<infinity> jkridner_: You bet.
<infinity> jkridner_: That would be the ideal outcome.
<prpplague> jkridner_: basically you;d want to have u-boot generate a SPL image that would be usable
<prpplague> jkridner_: on all three
<prpplague> jkridner_: it is doable, but takes some planning and testing
<GrueMaster> jkridner_: You should work with jcrigby from linaro.  He has been doing some interesting work with u-boot, like getting x-loader/MLO back into the u-boot tree.
<infinity> ^
<GrueMaster> Give me hardware and I can add it to my testing.  :)
<infinity> If you get any more hardware, your desk will collapse.
<jkridner_> prpplague: It is worth money to me if you can make it work. ;-)
<prpplague> jkridner_: same as GrueMaster ..... i'd need hardware
<jkridner_> GrueMaster: will do!  send me shipping info to jkridner at beagleboard (.org).
<jkridner_> ditto prpplgague, but I know where to find you.
<GrueMaster> infinity: I have a 1/3 empty industrial rack cabinet in the basement.  Space isn't an issue.
<CocoaGeek> bummer, I had -I/usr/include in the makefile â¦. ooopsy. Thanks to mkedwards on #linaro
<infinity> Wait, wait.  People are giving away toys?
<jkridner_> toys for promises of work.  output will be remembered. :)
<prpplague> hehe
<infinity> jkridner_: Well, screw that! ;)
<jkridner_> :)
<infinity> jkridner_: (But please do send one to GrueMaster, his testing is pretty invaluable)
<jkridner_> I will indeed.
<infinity> jkridner_: And if you're not already, do talk to jcrigby about this.
 * GrueMaster blushes.
<infinity> jkridner_: His work on the omap4 u-boot/mlo madness might be quite helpful in providing a way forward.
<jkridner_> if he'll chime in, it'd be good, but I'll check back at other times for him.
<prpplague> infinity: we must be talking about a different GrueMaster , the one i know is nothing but trouble
 * prpplague points to GrueMaster 
<prpplague> jkridner_: basically what we are talking about is a "bios" for omap series
<GrueMaster> What?  Me cause trouble?  I just find the bugs that annoy engineers to no end.  :P
<prpplague> hehe
<GrueMaster> Yes!  I have 6 pandas running in a cluster filesystem configuration.  How cool is that?
<jhobbs> oo
<jhobbs> what filesystem are you using?
<GrueMaster> ceph for this test.  Next will be GVFS.
<GrueMaster> It's a tad slow.  USB<>SATA and only 100mb ethernet, but still....
 * GrueMaster idly thinks about cell phone clusters.
<prpplague> GrueMaster: probably going to spin a second version of the bamboo with internal mounts for a 2.5 sata drive
<GrueMaster> Nice.  Is the sata more native or usb?
<GrueMaster> Also, I have had problems with the panda providing enough power for my usb drives.
<GrueMaster> (could be the drive cases).
<prpplague> GrueMaster: no it would be usb based, but we would have a secondary power rail for the usb hard drive so no worries on power
<GrueMaster> cool.
<prpplague> GrueMaster: rob clark is pushing for the new case
<GrueMaster> How soon unitl it is released?  I don't think I have seen an order option for it yet (but I haven't looked in over a month).
<prpplague> GrueMaster: probably not until jan, we have to see how the bamboo sells first
<prpplague> GrueMaster: bamboo should be available 1st week in november
<GrueMaster> Cool.  Look forward to seeing it in the wild.
<prpplague> GrueMaster: we keep debating on the color
<prpplague> GrueMaster: i think we've decided on matte black
<GrueMaster> Heh.
<prpplague> GrueMaster: but i think green would have been cool
<GrueMaster> Add a color "kit" option and ship a can of model paint.
<prpplague> hehe
<prpplague> circuitco is going to offer the pandaboard with the bamboo case and pcb pre-assembled
<GrueMaster> prpplague: I doubt it will fit my mini-cluster.  http://members.dsl-only.net/~tdavis/Panda-rack.jpg
<prpplague> GrueMaster: bamboo cases are stackable
<GrueMaster> Nice!
<prpplague> GrueMaster: bamboo also adds an additional sd/mmc slot
<jcrigby> jkridner_, I sent you an email, we can go from there
<jcrigby> jkridner_, btw infinity was too kind on the MLO from u-boot.  Aneesh V at TI did all that work, I just sorta watched.
<jkridner_> hi jcrigby.
<jkridner_> I'll take a look at the e-mail and come back.
<infinity> jcrigby: I didn't say you did all the work, just that you (appear to) know what's going on. ;)
<jcrigby> infinity, ok
<jcrigby> thats fair
<jkridner_> in my response e-mail, should I copy anyone besides jcrigby and prpplague and those already on the e-mail chain?
<prpplague> jkridner_: don't forget aneesh
<jkridner_> k
<prpplague> GrueMaster: hope you don't mind, i didn't think about asking until i had clicked the upload, i posted your pandaboard minicluster pic on my google+ account
<jkridner_> what is the rest of aneesh's name?
<jkridner_> or, some part of it so I can look up an e-mail addres.
<jkridner_> aneesh v?
<prpplague> aneesh@ti.com
<prpplague> jkridner_: yea
<jkridner_> prpplague: don't you worry about loggers sending spam when you post e-mail addresses?
<prpplague> jkridner_: i've not had any major issues with it
<SysTom> Anyone running arm on something like a pandaboard?
<prpplague> SysTom: running arm?
<SysTom> Yeah, OMAP4
<prpplague> SysTom: there are several ubuntu builds specifically for arm based devices such as the pandaboard and beagleboard, assuming that is what you are asking
<SysTom> Yeah, I'm just having a dig around now :)
<SysTom> Thinking about putting Ubuntu-server on this pandaboard...
<SysTom> Desktop seems rather I/O limited with the SD card
<SysTom> Hmmm, which versions *don't* require a serial cable, as I don't have one spare currently
<prpplague> SysTom: if you plan on doing any serious development on the pandaboard, the purchase of a cable would be wise
<SysTom> Seems that way, I just wanted to get something up and running tonight to play with
<GrueMaster> prpplague: Cool with me.  I posted it on my facebook.
<prpplague> cooloney: hey hey
<GrueMaster> SysTom: The server image is just as slow as the desktop on SD when it comes to I/O.
<GrueMaster> And the desktop image is better suited for non-serial console work.
<SysTom> Okay, good to know- I'll give that a go first
<SysTom> Just trying to set this SD card up properly
<SysTom> ... shouldn't be difficult right *rolleyes*
<prpplague> SysTom: if embedded linux was easy, they'd pay day-laborers to do the work
<GrueMaster> There is an issue where flash-kernel doesn't properly sync during the preinstall boot through oem-config, but it usually passes on the second time through.
<SysTom> prpplague: heh
<GrueMaster> prpplague: People get paid to work on this?  :P
<SysTom> I just wanted to get something vaguely up and running tonight
<SysTom> Stuck on preparing the SD, ... might just head to bed :D
<prpplague> GrueMaster: that;s what i hear
<GrueMaster> SysTom: If you have a usb keyboard and a HDMI or DVI monitor, desktop is your best bet.
<SysTom> I do
<GrueMaster> The SD needs to be 4G or greater.
<SysTom> I've got an 8GB SD card (with something already on it)
<GrueMaster> 8G seems to be the sweet spot.
<SysTom> In an ubuntu live environment now trying to get it sorted
<SysTom> ubuntu-11.04-preinstalled-netbook-armel+omap4.img.gz
<SysTom> ...and I'm downloading that as we speak
<GrueMaster> Make sure you back up your existing stuff on the 8G.  You will be blasting it away with this image.
<SysTom> That's fine, I don't need it (it was a spare SD card)
<infinity> "Blasting" makes writing to SD sound so much speedier and cool than it really is.
<infinity> "Trickling" might be more appropriate.
<SysTom> I *will* be making noises when it's flashing
<SysTom> Think Star Wars.
<infinity> Heh.
#ubuntu-arm 2011-09-10
<twb> lilstevie: OK, kernel building time
<twb> Is your tegralinux kernel available on git?  launchpad only tells me about the silly bzr lp: repo
<twb> Ha, and git.kernel.org is down of course, so I can't see mainline
<twb> nm, mainline is over there (github)
<twb> Wow that's a lot of CONFIG_ARM_ERRATA
<lilstevie> twb: https://github.com/lilstevie/linux_kernel_TF101 <-- runs on asus bootloader only, https://github.com/lilstevie/CrOS-Hybrid-Kernel <-- runs on u-boot only
<twb> Thanks.
<lilstevie> the CrOS kernel tree also has linaro packaging stuff in it cause I am getting ready to turn it into an installable package
<twb> I'm avoiding uboot for now because you said it's not ready
<lilstevie> bbiab
<twb> Oh, I see, that repo isn't a normal branch off of linux-2.6, it's just a tarball unpacked with some defconfig patches
<twb> mostly defconfig, anyway.  Some code changes and modules pulled in, too
<lilstevie> all android manafacturers only dirstribute their sources as tarballs
<twb> rassum frassum
<twb> But the cros one is big, so I guess that is a fork of a fork of a fork of ... back to mainline
<twb> (I'm still cloning that one.)
<twb> I guess what'd be useful is a synopsis of what does/doesn't work in each choice.
<twb> Is l4t just the graphics driver, or is it more than that?
<twb> afk playing computer games
<lilstevie> cros kernel is the chromeos kernel, but it also is required for acceleration
<twb> ok
<lilstevie> have fun with games?
<twb> ya
<lilstevie> what were you playing
<twb> Deus Ex 3
<twb> So I'm going to try using multistrap to build a Debian armhf chroot dir, then initiall try uploading it as a simple 512MB ext2 rootfs to the APP partition.
<twb> I'm still dithering about which kernel to use
<twb> Yay for qemu-user-static and binfmts, I can just chroot into it :-)
<lilstevie> you should just repartition and make your own partition layout :p
<twb> OK
<twb> Presumably I should avoid moving around the other partitions, tho
<twb> like don't mess with EBT
<twb> dpkg: warning: parsing file '/var/lib/dpkg/status' near line 4 package 'dpkg': missing description
<twb> ...sigh
<SysTom> ubuntu-11.04-preinstalled-netbook-armel+omap4.img <- DD'd that across last night, I'm not getting any output from the display- this *isn't* the headless version- right
<twb> lilstevie: comparing arch/arm/configs/tegra_defconfig  arch/arm/configs/tf101_gnulinux_defconfig in CrOS-Hybrid-Kernel repo, why does the latter have lots more stuff in it?  Like, even CONFIG_ARM=y isn't set by the former.
<SysTom> Also does it matter that I dd'd it over with a 16M block size
<lilstevie> twb: anything after EBT is fine :p
<lilstevie> just keep SOS and LNX as the partition identifiers for the kernels
<lilstevie> twb: also the reason is tegra_defconfig is a minimal config, which gets populated with defaults from the Kconfig
<lilstevie> but the tf101_gnulinux_defconfig is me just coping the working .config in place
<ssam> i have put an ubuntu headless image onto an sd card for a beagle board, by instructions https://wiki.ubuntu.com/ARM/OMAPHeadlessInstall
<ssam> if i run fdisk on the partition it made i get "The filesystem size (according to the superblock) is 390546 blocks" "The physical size of the device is 389576 blocks"
<ssam> my sd card is 4GB
<ssam> is there a way to fix this?
<ssam> ah, think i may have found the answer at http://irclogs.ubuntu.com/2010/08/24/%23ubuntu-arm.txt
#ubuntu-arm 2011-09-11
<twb> re defconfig -- that's what I guessed.  Would be nice to distill it down sometime.
<twb> lilstevie: what is "the blobs-be-gone enhancement"?
<Galaxor2> Hi. So I installed an ubuntu chroot on my andoid tablet using debootstrap. Debootstrap didn't give me a sources.list. (Actually it gave me an empty one). So I made myself a sources.list and ran apt-get update. It 404ed on all the repos. What is up? Here's my output from apt-get update: http://pastebin.ca/2080718
<twb> Also, why is http://lilstevie.geek.nz/ports/nvflash-ubuntu.tar.gz a tarball when it contains only one file.
<twb> Galaxor2: resolv.conf
<Galaxor2> Hm. Resolv.conf exists and has the contents I expect. debootstrap doesn't seem to have installed any other programs capable of attempting to resolve domain names, so I can't check it with another program. I don't have host or ping or wget pr nslookup...
<twb> libc performs hostname resolution
<twb> Try "getent hosts"
<twb> Or just put IPs in sources.list for now
<twb> I mean "getent hosts example.net".  Also check nsswitch.conf, I guess.
<Galaxor2> getent hosts ubuntu.com resolved it.
<Galaxor2> Also I notice that the error I was seeing was not a hostname lookup failure but a 404. The webserver was in fact contacted.
<twb> Then I dunno
<twb> Sorry, I should've read your error pastebin, I just jumped to the DNS conclusion
<twb> Your problem is that armel isn't carried on that mirror
<twb> It looks like armel isn't hosted in the normal archive at all.
<Galaxor2> Mrr...? Where should I look for the armel stuff? Debootstrap seems to have found it somewhere...
<twb> Dunno, I use Debian.
<Galaxor2> Ha. I have sometimes gone to #debian for help if I have a general enough problem but they always get mad at me when they find out I'm actually using ubuntu. I guess the rivalry isn't so intense in the other direction.
<twb> It's more that I'm asking lilstevie for help and he is here, not in #debian-arm
<twb> I do use ubuntu x86-64, but not arm.
<Galaxor2> Aha.
<Galaxor2> Ok, I  found the answer. In my sources.list, I s/us.archive.ubuntu.com\/ubuntu/ports.ubuntu.com/. That did the trick.
<lilstevie> twb: it is a tarball to make it smaller
<lilstevie> it is a 4GB image or 950MB compressed
<twb> Why not gzip it
<twb> An archive of one file is silly
<twb> I mean: ubuntu.img.gz rather than ubuntu.img.tar.gz
<lilstevie> eh
<lilstevie> doesn't really matter tbh
<twb> I guess not, it's just a bit wasteful
<twb> lilstevie: what's the GPT partition table for?
<twb> When you said yesterday that I can blow away everything after EBT, I think that GPT needs to stay
<lilstevie> when I say you can blow it away I mean that they are mobile
<lilstevie> GP1 and GPT are bookends
<lilstevie> GP1 at the start and GPT at the end, everything between them will be able to be addressed from /dev/mmcblk0px
<twb> OK, let me put it this way.  default.cfg ships with: BCT, PT, EBT, SOS, LNX, BAK, GP1, APP, CAC, MSC, USP, PER, YTU, UDA and GPT.  Of these,
<twb> BCT, PT, EBT, GP1, GPT -- leave these completetly as is.
<twb> BAK, APP, CAC, MSC, USP, PER YTU, UDA -- can all be removed.
<twb> LNX and SOS should exist, but everything except the label can change
<twb> Is that right?
<lilstevie> everything else is irrelevant if you aren't using android
<lilstevie> my current layout is MBR for u-boot
<lilstevie> but I have BCT PT EBT as standard
<twb> Oh, OK
<twb> I thought you needed e.g. EBT still if you wanted to use nv3p/nvflash
<lilstevie> then MBR UES (u-boot environment store) UIM (u-boot information and media) UBT (ubuntu) MPT(MBR Partition Table endpoint)
<lilstevie> nv3p resides in the bootloader you upload
<twb> And the APX stuff is baked into a separate ROM, and I *can't* accidentally host it?
<lilstevie> EBT is so it is picked up as the bootloader during boot
<twb> s/host/hose/
<lilstevie> correct
<lilstevie> APX is baked into the SoC
<twb> in allocation_attribute, which 8 in 0x808 is "allocate to the end of the disk"?  And what does the other 8 mean?
<lilstevie> the allocation attribute as a whole means that
<lilstevie> 0x808 is the allocation attribute to allocate to end of disk
<twb> OK
<twb> Oh, I misread.  YTU has 8, UDA has 808
<lilstevie> in which case size= is an exclusion
<lilstevie> YTU has 8 UDA has 0x808 :p
<lilstevie> there is a difference
<twb> Yeah sorry
<twb> What do you mean by exclusion?  As in, leave that much off the end unallocated?
<lilstevie> yep
<twb> You omitted "ro" from the recoveryimg.cfg -- any reason for that?
<lilstevie> accident
<twb> k
<lilstevie> nobodys perfect :p
<twb> OK, do you expect this to result in something that'll boot?
<twb> http://paste.debian.net/129314/
<twb> Oops, the id=3 in flash.cfg doesn't match your bootimg.cfg abootimg args
<lilstevie> ?
<twb> I'm doing a first test using your kernel, ramdisk and rootfs, so that I know that much of the process works, and because building a rootfs is a bit more tedious than I hoped
<twb> You have root=/dev/mmcblk0p8, but I has set the partition number to 3 in flash.cfg
<twb> Although when I look, your purelinux.cfg sets UBT to id=16, so clearly those don't need to match up
<lilstevie> it is a bit different to that
<lilstevie> your thing is wrong
<lilstevie> btw
<lilstevie> BCT must be ID2 PT needs to be 3
<lilstevie> and the config starts from 2
<twb> Thought you said I didn't need that stuff since I wasn't using android
<lilstevie> nonono
<lilstevie> if you read I said that is the bare minimum you must keep always
<twb> OK, sorry
<lilstevie> that is a requirement from the tegra2
<twb> http://paste.debian.net/129315/ how about that
<lilstevie> ok better
<lilstevie> but
<lilstevie> still one more thing
<twb> Yeah?
<lilstevie> you need to wrap in a partition format
<lilstevie> for the partitions you want to have a /dev/mmcblk0px
<twb> Aaaah, that's how it gets to p8 being UBT in your one
<lilstevie> well it is p8 because it is the 8th partition after the GP1
<lilstevie> count them :p
<twb> Yeah
<twb> I get that now
<twb> Do you also put LNX and SOS "inside" GP1/GPT, so that you can reflash them from within the TF101?
<twb> Or can flash-kernel(?) do that without a mmcblk0px ?
<lilstevie> yes that is the "blobs-be-gone" enhancement
<lilstevie> anything outside is a pita
<twb> OK, I think I get that
<twb> And if I calculate correctly, your purelinux.cfg leaves space at the end for 1MB more than the size of LNX+SOS+UBT -- is that the space required for the GPT partition?
<lilstevie> thats the placeholder space yes
<twb> OK.  And you have GP1 and GPT because it's basically GPT-style partitioning, and that's why you're also passing "gpt" to the kernel in bootimg.cfg?
<lilstevie> yes
<lilstevie> the GPT on the command line is to force though
<twb> OK
<lilstevie> because the GPT at the end of the disk ALA traditional GPT doesn't actually work
<lilstevie> it needs to use the backup GPT which is located at GP1
<twb> Is that because nvflash is fucked up, or what?
<twb> I mean: why is the end-of-disk GPT buggered
<lilstevie> yeah
<lilstevie> nvflash is badly put together
<twb> OK, I'm trying it now
<twb> Heh, no asus splash, it was going straight into APX mode and I didn't realize at first.
<twb> (My first upload failed because I told it to use EBT.bin but the file was called EBT.img.)
<lilstevie> heh
<twb> And again with recovery.img vs. SOS.img
<twb> It seems that after it bork borks, I need to reboot back into APX mode
<twb> lilstevie: could you use e.g. parted from inside the TF to fix the GPT partition?
<twb> Goddammit, OS.img is too large for partition
<lilstevie> oh yeah
<lilstevie> this is another issue due to how poorly nvflash is coded
<lilstevie> remove filename= from the config
<lilstevie> after the create go back into APX
<twb> and use --download?
<lilstevie> then --download
<lilstevie> yeah
<lilstevie> also no parted does not work
<twb> Is that because the validation thing doesn't check if size is 0x808'd ?
<lilstevie> due to the lack of pmbr
<lilstevie> correct
<twb> parted speaks GPT
<twb> Not just msdos I mean
<lilstevie> yeah parted speaks mbr but it likes a protective mbr
<twb> Oh right
<lilstevie> to let it know that it is GPT
<twb> Ooh
<twb> It rebooted and I got penguins and into initramfs prompt
<twb> It was even fast
<lilstevie> :)
<lilstevie> ok so now drop her back into APX
<lilstevie> and upload that nice osimg
<lilstevie> now, do you have a  dock?
<twb> yeah
<lilstevie> ok
<twb> Can't hit volup fast enough anymore, it boots too quick :-/
<lilstevie> hold volup and power
<lilstevie> not power then volup
<lilstevie> :)
<twb> oh, that kicks in *after* the penguins
<twb> I thought I had to hit power, then hold both while I had the asus splash logo
<lilstevie> nah
<lilstevie> bootrom man :p
<lilstevie> needs to detect that button within a few hundred miliseconds of the reset vector
<twb> I'm used to PCs where if you get penguins you have missed the boat
<lilstevie> so as long as both are triggered at the same time if not before power you are good
<twb> Oh fuck, I really shouldn't have done --download from within Emacs' terminal
<twb> I can see it writing each char of b y t e ... s
<lilstevie> lol
<twb> Hmm, it seems to be doing the writes themselves OK, though
<twb> It's done 10% of the 2GB already
<twb> Maybe nvflash is smart enough to STFU and write progress slowly if you have TERM=dumb or something
<twb> Am I write in thinking the eMMC is going to have a "modern" number of writes?
<lilstevie> yeah
<lilstevie> it is a toshiba nand
<twb> I mean, it's not like those really early MTD devices where you get like 100 writes and then you're fucked
<lilstevie> well at least on the 16GB one
<lilstevie> and a hardware drivven FTL
<twb> Yeah
<twb> Although it would be nice if I had an open implementation of the FTL, to go with Coreboot and OpenFirmware ;-)
<twb> 50% done
<lilstevie> heh
<lilstevie> well when we are looking at the FTL is so hw driven that the raw device is post processing
<twb> 100% done, now to reboot
<lilstevie> ./nvflash -r --go will work too
<twb> Can I issue a reboot via nvflash, or do I need to let the kernel-
<twb> Ahahahaha
<twb> It's refusing to work because the ext last-mount timestamp is in the future.
<lilstevie> lol
<lilstevie> you never booted android once did you?
<twb> Right
<lilstevie> RTC wasn't set :p
<lilstevie> you could always drop into single and run fs recovery though right?
<twb> Actually I did but then I reset it to factory defaults, and I couldn't get it on the network because I use WPA2 Enterprise, and I couldn't get it to recognize an ext2 SD card with the SSL cert on it
<twb> single â  break
<lilstevie> idk
<twb> I will try tho, because otherwise I need to reupload the whole rootfs again
<lilstevie> I have not had a problem with the RTC losing time though
<twb> oh nm I can just hit "stfu fsck, continue anyway"
<lilstevie> hah
<twb> I am so used to mountall just completely failing
<twb> esp. with diskless clients
<lilstevie> ah
<twb> Screen is nice and high-res compared to my 1005PE
<twb> The map part of ubuiquity still needs work tho, hard to pick melbourne instead of hobart or sydney with my chubby fingers
<lilstevie> so tsp is working?
<lilstevie> awesome
<twb> yeah single touch anyway
<lilstevie> heh I have skinny fingers and it is still hard to pick melbourne
<twb> The trackpad thing beneath the keyboard isn't
<lilstevie> yeah expected
<lilstevie> there is a patch for that somewhere in the thread on xda-devs
<twb> keyboard is, which is the importantest thing
<lilstevie> yeah
<lilstevie> keyboard works great
<lilstevie> keymap could do with a tweak
<lilstevie> which it does have in teh uboot kernel
<lilstevie> if you compiled from my 2.6.36.4 kernel though you have the important 2
<lilstevie> esc, and ctrl
<twb> I'm currently just testing your pre-compiled kernel
<twb> The APX-flavoured one, not the u-boot flavoured one
<lilstevie> oh so you didn't compile your own?
<lilstevie> :p
<twb> Not yet
<twb> I think I want the CrOS one but then I need to learn about u-boot
<twb> And having my own rootfs is more important than my own kernel, at least until Debian starts pre-rolling them for me with everything =m
<twb> :-)
<lilstevie> heh yeah
<twb> Stupid password checker thinks passwords are weak unless they contain at least one uppercase character
<lilstevie> I already have tat
<lilstevie> but meh, bruteforcable passwords are not the issue that todays society faces
<lilstevie> it is password entropy :p
<twb> My old laptop has no password at all
<twb> If you want to log in remotely you have to use multifactor auth
<lilstevie> I use cert based authentication myself
<twb> One of the things I'm thinking about doing is LUKSing the user partition
<twb> And keeping the something-you-have on an SD card or something
<lilstevie> heh
<twb> Hmm, it's looking for /lib/modules/2.6.38-8-omap/modules.dep
<twb> When oem-config finishes I have a white bar down the left, presumably there are supposed to be apps there
<lilstevie> hmm you are using the ubuntu fs?
<lilstevie> the bar is white due to a bug in unity
<twb> ok
<twb> the apps take quite a while to come up
<twb> Even for gnome
<twb> Is it supposed to wake up from suspend?
<lilstevie> button
<lilstevie> the power one, push it
<twb> it didn't like it
<lilstevie> sometimes it glitches waking up though
<twb> Also the backlight was still on
<lilstevie> oh, that isn't suspend
<twb> I managed to power it off by holding the power button down
<lilstevie> that is just screensvaer
<twb> I put it into suspend by hitting power button and picking suspend frmo teh gnome-power-manager popup
<lilstevie> power management is up the creek though
<twb> Nod
<lilstevie> due to how android handles it vs. a real os
<twb> I remember all that wakup crap that android wanted to get into mainline
<lilstevie> wakelocks
<twb> ya
<lilstevie> the most god aweful system ever :p
<twb> yeah, well I'm not a fan of upstart or polkit/consolekit or udisks either :P
<lilstevie> heh
<twb> I guess i can expect at least 30% faster once I switch to armhf
<twb> I was talking to somebody yesterday and they said "so when you have the tablet part disconnected, how does the kb work... bluetooth?"
<twb> And damn that would be awesome if it did
<twb> In unity, where's the equivalent of the gnome preferences menu?
<lilstevie> well
<lilstevie> there isn't really one
<twb> the scrollbar in the gnome appearances pane is really fucking with my head, I can't work out how to make it scroll
<lilstevie> it is a bit odd to get used to
<twb> It's got a little thin bar instead of a scrollbar, and when I try to scroll on it, an up/down arrow thing appears, but doesn't seem to do anything
<lilstevie> hold the up/down arrow thing and drag it
<twb> OK I got it
<twb> That would give Fitts a fit.
<twb> Is that part of that libhildon stuff that nobody uses?
<lilstevie> no idea where it comes from but it is in unity
<twb> It's not smart enough to know it's upside-down, either
<StevenK> Unity does not make use of hildon
<twb> k
<twb> There should probably be an easy way to start onboard from within unity or gnome
<lilstevie> there is :p
<twb> Boy, I hope I can remap the magnifying glass to Alt_L
<lilstevie> twb: yeah look at my 2.6.36.4 kernel
<lilstevie> already done :p
<twb> That's what I'm running isn't it
<lilstevie> nah, the prebuilt one is the asus drop
<twb> But surely you can do it in /etc/default/kbd or so
<lilstevie> yeah
<lilstevie> you can edit the keymap too
<twb> Looks like the asus one has RT stuff in it too
<twb> That's what "PREEMPT" means, right?
<twb> What's /bin/adbd?
<lilstevie> adbd :p
<twb> Yeah but what is it.  There's no manpage
<lilstevie> thats because it is from android
<lilstevie> android developer bridge daemon
<twb> And it's not provided from deb
<twb> Ew
<lilstevie> that is so people without a dock can get through ubiquity
<twb> Presumably it does something useful even when there's no android?
<lilstevie> yeah it allows usb connection using adb
<twb> Oh, it's an RPC listener to allow you to connect from other other- right
<twb> FYI, it's still running even after ubiquitity is done and a restart
<lilstevie> yeah,
<lilstevie> it is started every boot
<lilstevie> it does have more uses than just ubiquity
<twb> k
<twb> It just sounds to me like an attack vector
<lilstevie> heh
<twb> Gah, I'm so used to Caps being a control key
<twb> This is why I never learnt dvorak â too disonnant on random other devices
<twb> *dissonant
<lilstevie> twb: adbd may be an attack vector, but that is moot as you would already have the device in your hands :p
<twb> Yeah, I *mostly* agree with that
<lilstevie> adbd ONLY works over usb
<lilstevie> :p
<lilstevie> as it requires the kernel interface
<twb> resize2fs worked on the device, as expected
<twb> IOW I made a 2G image from your 4G one, uploaded that, then grew it to the full ~30GB
<lilstevie> yeah
<lilstevie> my new image is 2GB
<lilstevie> just need to get around to uploading it
<twb> Hmm, bluetooth doesn't work?
<twb> Hmm, in /sys/class/power I have ac, battery and usb
<twb> Where's the second battery?
<twb> Hmm, acpid isn't installed
<twb> lilstevie: when you build your kernels, do you use "make deb-pkg zImage" or what?
<lilstevie> twb: the second battery stats arent in all kernels
<lilstevie> bluetooth requires you to compile brcm_patchram_plus
<twb> Hum
<lilstevie> and no I just make CROSS_COMPILE= LOCALVERSION= BLAH=
<twb> On all the other Eee's I just leave this stuff to SynrG to get folded into the debian kernel :P
<lilstevie> and been using linaro packaging to get debs build
<twb> deb-pkg is handy because it gives you a deb with the =m .kos
<lilstevie> linaro packaging does too
<twb> Well, I'm done for today.
<twb> See you next weekend or so
<lilstevie> haha kk
<travalas> Hello, I'm trying to get networking up on a beagleboard-xM
<travalas> what is the recommended module
<travalas> ?
<rsalveti> travalas: smsc95xx
<travalas> is anybody here using natty on a beagle board-xM rev C?  I installed it and ethernet and usb doesn't work
#ubuntu-arm 2012-09-03
<orated> Hello! I'm getting "qemu: Unsupported syscall: 184" lines after running almost every command on chroot using  qemu-arm-static emulator. What does the repeated lines mean?
<sangwook> hggfu
<sangwook> dzfadsfewcd xzcccpogtffffftttgg
<sangwook> tmp2362
<sangwook> gffdgtzfdg
<LetoThe2nd> sounds like the brainfuck to IRC converter is broken.
<ogra_> or the cat wants to tell us something :)
<LetoThe2nd> ogra_: that would be more vowels and less consonants then.
<ogra_> heh, true
<lilstevie> lol
<ogra_> rsalveti, with the next imae build all will be ready on panda, could you or alf_ take a look at the flickering ? its really bad
<ogra_> *image
<rsalveti> ogra_: I'm checking that, needs just a kernel update
<rsalveti> at least it seems that unity is working without crashing
<ogra_> rsalveti, yeah, unity is fine, firefox is horribly slow thouh
#ubuntu-arm 2012-09-04
<beyond_> qgis porting to beagleboard help?? anyone here?
<beyond_> qgis porting to beagleboard help?? anyone here?
<LetoThe2nd> beyond_: smart questions, anyone read?
<LetoThe2nd> beyond_: http://www.catb.org/esr/faqs/smart-questions.html
<beyond_> qgis porting to beagleboard ubuntu error.. Help please
 * LetoThe2nd sighs and heads back to work.
<lilstevie> LetoThe2nd, I like it
<LetoThe2nd> lilstevie: what specifically
<lilstevie> the smart-questions faq
<LetoThe2nd> lilstevie: its awesome. too bad nobody ever reads it.
 * lilstevie is reading it right now
<ogra_> rsalveti, bug 1045491 for you
<ubot2`> Launchpad bug 1045491 in pvr-omap4 "Moving mouse messes up the desktop" [High,Confirmed] https://launchpad.net/bugs/1045491
<ogra_> rsalveti, hmm, i struggel to get any monitor output on the server image ... is there any trick to make that work if no xserver and no pvr driver are installed ?
<ogra_> yippie, my new ac100 screen arrived
<ogra_> marvin24, do you happen to know if i still need the kernel hacks if i want to use a 1280x720 panel with the 3.1 kernel ?
<marvin24> ogra_: yes, the resolution is hard coded
<ogra_> k, sad
<marvin24> maybe we could read out the edid
<marvin24> but I have no idea how
<ogra_> well, i guess it would be fixed if i used a kms enabled kernel
<marvin24> not really
<marvin24> no edid, no autoresolution
<ogra_> oh
<marvin24> the schematic says something about a ddc connection, though
<ogra_> i thought kms would rely on EDID data
<ogra_> anyway, first i need to replace the HW :)
 * ogra_ is a bit scared to remove the bezel
 * LetoThe2nd hands ogra_ an "r"
<ogra_> lol
<ogra_> bavarians ...
<LetoThe2nd> \o/
<LetoThe2nd> a bavarian would never call it "brezel" though, but "brezn"
<ogra_> oh, indeed
<marvin24> ogra_: yes, kms needs it
<marvin24> but there's a hard code hack ...
<ogra_> lovely
<marvin24> seems the ddc data path is only connected to the hdmi port
<ogra_> well, i'm willing to live with a hack if needed, after all 720p panels arent std on the ac100
<ogra_> (and i wouldnt have bought it if one of my ac100s wouldnt have a cracked screen)
<rsalveti> ogra_: what is the issue with the server image? in theory you should be able to get the boot log or the console login interface just fine
<rsalveti> unless your panda is not recognizing your monitor from the kernel side, at least not during boot
<rsalveti> and the modeseting from pvr-omap4 is the one enabling and starting your monitor properly
<ogra_> rsalveti, it works just fine when doin a serial install, but without console= set no screen comes up on the monitor
<ogra_> there is no pvr on server installs
<rsalveti> ogra_: and thanks for the buglink, got the kernel to build here, will give it a try now
<ogra_> we cant ship X there
<rsalveti> that's fine, the kernel should still be able to set up the correct resolution and get everything in place for you
<rsalveti> even if you're not using X
<ogra_> you mean if i dont have pvr installed ?
<rsalveti> let me boot with text and see if I can reproduce your behavior
<rsalveti> yup
<ogra_> i dont even get a console after install :/
<ogra_> [    0.288848] omap_sr_disable: omap_sr struct for sr_iva not found
<ogra_> [    0.291564] omap_hwmod: sl2if: _wait_target_ready error: -16
<ogra_> thats the only error i find in dmesg
<ogra_> well, a few more omap_sr errors
<rsalveti> adding drm.debug=7 omapdss.debug=1 might help us understanding what is happening
 * ogra_ does
<ogra_> http://paste.ubuntu.com/1185592/
<rsalveti> ogra_: here it seems to work fine, after booting with 'text'
<ogra_> rsalveti, what is bothering is that it works just fine on desktop ...
<rsalveti> the monitor turned itself on while opening the tty1 console
<ogra_> on a server image ?
<ogra_> note that desktop has no issues here either
<rsalveti> no, desktop, but with 'text' the X11 it not even started
<ogra_> and it didnt with the alpha release (where we had no pvr)
<rsalveti> let me check the logs
<rsalveti> ogra_: when booting your desktop image, do you always see the splash before X11 starts?
<ogra_> hmm, i didnt check, i think i didnt see it after install, but before
<ogra_> i.e. booting the image showed it ... but it was gone after booting into the installed system
<rsalveti> ogra_: also, can you check what happens when you use the dvi output instead of hdmi?
<ogra_> already tried, no change
<ogra_> i would blame my monitor (LG) ... if it wouldnt work just fine in desktop
<ogra_> with the same kernel
<ogra_> [  508.846771] omapdss DISPC: channel 1 xres 1920 yres 1080
<ogra_> [  508.879577] omapdss HDMI: hdmi_runtime_get
<ogra_> [  508.879608] omapdss HDMI: hdmi_runtime_put
<ogra_> [  508.879608] omapdss HDMI: Enter hdmi_display_disable
<ogra_> seems thats printed over and over in dmesg now
<ogra_> ogra@panda:~$ who
<ogra_> ogra     tty4         2012-09-04 14:01
<ogra_> ogra     pts/0        2012-09-04 13:51 (192.168.2.91)
<ogra_> after logging in blindly ...
<ogra_> so getty is there and i can log in ... just cant see a thing
<rsalveti> there's a lot of sync_lost as well...
<ogra_> yes
<rsalveti> let me just give the new kernel a try (with in theory fixes the flickering issue)
<rsalveti> this new kernel changes quite a few bits at the dss and display driver
<rsalveti> and reverts a few changes for omap5 as well
<ogra_> ok
<ogra_> if you think it hleps i can test here too
<rsalveti> sure
<ndec> rsalveti: so you decided to go with the ~try kernel?
<ndec> where do you host the code? it's not coming from tilt-3.4..
<rsalveti> ndec: not yet, still checking what would be the side effects
<rsalveti> we're using robclark's tree
<ndec> yeah, i know.
<ndec> but it breaks some display interface such as DSI at least. not sure if some of your users will care about that.
<rsalveti> yeah, that's one of the issues I noticed here as well
<ndec> DSI? you mean DVI, no?
<ndec> there is a cleaner solution that has been designed in omapdss, to fix the same issue. and that is being planned for upstreaming in the upcoming kernel.
<rsalveti> what is the current state of that?
<rsalveti> because we either go with the same solution from ~try or decide to backport the proper one that will land upstream later on
<ndec> i am hoping that we will get omapdss changes in our upcoming 3.6 tree.
<rsalveti> but there are a bunch of omap5 related changes at our tree as well
<ndec> and i am also interested in a backport of the 'clean' solution.
<ndec> omap5?
<rsalveti> because we got the tree from ti-3.4 branch
<ndec> and what do you call 'our' tree in fact? is it Andy's tree?
<rsalveti> yup
<ndec> yes, tilt-3.4 has some support for OMAP5, even though it's still missing a few bits. we have another tree we use for full releases on OMAP5.
<ndec> we will get a tilt-3.6 eventually with similar 'feature' set as tilt-3.4. except that our primary 'dev' and test platform will become OMAP5, instead of OMAP4.
<ndec> and that we will get the rework from omapdrm/omapdss.
<ndec> for OMAP4 'products' we will continue to use tilt.3.4, well our TI tree based on tilt-3.4
<rsalveti> got it
<robclark> rsalveti, DVI should be working on my branch
<rsalveti> robclark: yup, but for some reason I'm not even getting my hdmi out to work
<rsalveti> still trying to understand why
<rsalveti> had to disable OMAP2_DSS_VENC and OMAP2_DSS_DSI for it to build
<robclark> rsalveti, hang on, I can pastebin my .config for you to cross check against
<robclark> rsalveti, http://hastebin.com/raw/gopiweniqi
<rsalveti> robclark: thanks, will check here
<robclark> rsalveti, btw, the weston shader optimizations were pushed to master last fri.. this should give a nice performance boost w/ pvr
<rsalveti> robclark: cool, nice to know
<plars> ogra_: heya
<plars> ogra_: on https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1045788 - I was trying ubuntu-server on my panda this morning and I'm seeing something very different
<ubot2`> Ubuntu bug 1045788 in linux-ti-omap4 "screen on quantal server images stays black" [High,New]
<plars> ogra_: with hdmi plugged in, I see the language selection screen come up, but my keyboard does not work
<rsalveti> plars: hey :-)
<plars> hey rsalveti
<plars> rsalveti: your name sounds familiar...have we met?
<plars> :-b
<rsalveti> plars: ;-)
<rsalveti> plars: so I guess you're at least getting your screen to work properly?
<rsalveti> the usb issue is a bit weird
<rsalveti> I'd not be surprised if this screen issue is related with the monitor you're using
<rsalveti> as I'm able to get it to work here just fine as well
<rsalveti> and ogra_ seems to be getting a bunch of hdmi_display_disable messages after boot
<plars> rsalveti: yeah, likely
<plars> rsalveti, ogra_: also, even with serial, mine appears to get stuck at some point... just have a black screen now after going through a couple of steps
<rsalveti> :-(
<plars> wow, not sure what that was
<plars> I got it back though
<plars> no ^c or ^z, I think ^d finally did it
<plars> it was after network detection, after it asked me for hostname
<plars> screen just went black
<plars> now after ^d it continues though
<plars> if you didn't see this, maybe I will try to reimage this and reproduce in a moment... let me get through it as is for now thoug
<plars> oh, you have to manually make a partition on it now?
<ogra_> plars, ??
<ogra_> plars, you need to install to USB nowadays
<ogra_> or yes, jump through several hoops and pre-partition the SD (with / and swap at minimum)
<ogra_> apart from the screen issue both, omap and omap4 server images work fine for me
<elfy> I have finally managed to get omap4 installed - happened to see an "omapdss HDMI error : failed to enable GPIO's" in a tty - is that a known thing or should I report it - if so what should I report it against - thanks for any help :)
<elfy> or is it tied up with https://bugs.launchpad.net/ubuntu/+source/pvr-omap4/+bug/1045491
<ubot2`> Ubuntu bug 1045491 in pvr-omap4 "Moving mouse messes up the desktop" [High,Confirmed]
<ogra_> does your system behave as expected otherwise ?
<elfy> I believe so ogra_ - this is the first time I've managed to get installed :)
<ogra_> i think it prints that every time you swithc the display context ... i.e. from X to a tty or back, i see that here too
<elfy> aah ok - thanks
<elfy> though it is very very slow to respond to mouse
<ogra_> hmm, i didnt find it slow
<ogra_> i found firefox extremely slow though
<ogra_> everything thats 3D rendered seemed fine
<ogra_> (i dont think it is  slower than unity-2d was with the framebuffer driver in 12.04)
<ogra_> but thats indeed totally subjective :)
<elfy> 7 seconds to report back from free -m in  aterminal, 20 secs to give the me the shutdown menu, a long time for nautilus to show anything
<ogra_> oh, thats disk I/O ... i thought you referred to graphics
<elfy> I was responding to " does your system behave as expected otherwise"
<ogra_> well, using USB for / simply limits you to the max 24MB/s you can pump through a USB bus
<ogra_> thats still a lot more than with SD, but its just USB after all
<elfy> aah ok - so that is 'expected' - if I'd thought more I'd have not asked lol
<ogra_> also note that there are a lot of tasks running right after install
<elfy> ok - so yea - as far as graphics - I just have that bug I linked then
<ogra_> update-xapian-index ... locate ... lots of processes that put a horrible load on the little panda
<elfy> yep
<ogra_> try to let it sit fro 30min until all these bits are done
<elfy> ok
<ogra_> and also do an additional reboot, that helps ureadahead to set up a better profile
<ogra_> (i think it uses three runs (each run at a fresh boot) to actually build the proper profile
<ogra_> )
<elfy> ok - will do that - and then see how it looks - thanks ogra_
<ogra_> thanks for helping !!!
<ogra_> :)
<elfy> welcome  :)
 * ogra_ is happy about every additional tester
<elfy> lol
<elfy> I blame balloons - so you are safe :)
<ogra_> haha
<elfy> I test this and xubuntu - ubuntu has enough people :)
<ogra_> true
<ogra_> (though i bet plars would disagree ... )
<elfy> :)
<elfy> I guess there's never enough people testing in truth
<ogra_> yeah
<balloons> hah!
<elfy> ohai balloons
 * balloons waves at elfy 
 * elfy would wave back but the channel's logged ... :p
 * ogra_ ponders if having the bootloader partition automounted after install is a bu or not
<ogra_> *bug
<ogra_> we used to hide it in the past
<ogra_> yay, my ac100 kernel with 1280x720 hack works
<lilstevie> ogra_, nice, I kinda want an ac100
<lilstevie> seems like a bit of fun
<ogra_> buy one then :)
<lilstevie> hah
<LetoThe2nd> far too expensive.
 * lilstevie doesn't think he could convince the mrs that he needs it
 * LetoThe2nd repeatedly thought hard about if he needs another arm tablet/notebook device. i couldn't find any use case, so the answer obviously is no.
<ogra_> LetoThe2nd, http://www.amazon.de/Toshiba-AC100-10V-Netbook-Android-schwarz/dp/B003YJ67T2
<ogra_> 169â¬
<xnox> hmm... good price.
<xnox> ogra_: do they ship to UK?
<ogra_> i think you can still get them used on amazon.co.uk somewhere :)
<LetoThe2nd> ogra_: jsut for _having_ but not _using_ 170â¬ is still too much.
<ogra_> xnox, you likely dont want a german kbd :)
<xnox> ogra_: yes. I want US one
<ogra_> there are no US ac100's
<plars> ogra_: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1045855 any suggestions what else I could try here?
<ubot2`> Ubuntu bug 1045855 in linux-ti-omap4 "usb keyboard doesn't work during installation of ubuntu-server on panda" [Undecided,New]
<ogra_> uk, fr, russian, german iirc
<TypoNAM> ogra_: US never gets the cool toys :/
<ogra_> plars, do you have a serial console enabled when it doesnt work ?
<xnox> ogra_: according to amazon.co.uk 169 EUR is 287 GBP, instead of 133 GBP
<ogra_> i have seen d-i take the input from serial while displaying on framebuffer before
<plars> ogra_: I do, but when I switch over to the serial pre-env, it seems that nothing is shown on the graphical display, so there's nothing to interact with
<ogra_> xnox, heh, yeah, they are bad at math ... especially when it comes to GBP
<plars> ogra_: I did try pressing keys on the serial console, just to see if it would affect what was happing on my screen, no luck
<ogra_> plars, well, for laughs, try hitting the up/down keys in your serial console and watch the monitor
<xnox> ogra_: i think they thing they are rather good with math, and customers aren't
<plars> ogra_: yeah, tried that
<ogra_> ah, you did
<plars> I'll play with it some more later... let me get through some more tests
<ogra_> yeah, as lon as seerial works i'm not too concerned
<ogra_> plain serial installs are fine for server ...
<ogra_> (not that we dont need to fix this, but its not a beta blocker imho)
<plars> ogra_: right
<plars> I know what you mean :)
<plars> it's possible to install for sure, so it's good enough for beta
<ogra_> yep
<ogra_> i'll have to write a little novel for the release notes though
<GrueMaster> Not sure if anyone has seen this yet, but it looks interesting.  http://cubieboard.org
<ogra_> like a beaglebone :)
<GrueMaster> Except half price & with video + SATA.
<prpplague> that an all-winner based?
<prpplague> ahh right
<prpplague> yea A10
<ogra_> the headphone jacks are really clever placed
<prpplague> indeed
<suihkulokki> someone needs start mainlining the allwinner stuff
<prpplague> hehe
<rsalveti> another allwinner based board?
<wookey> yep
<wookey> very cheap, and mali GPU
<rsalveti> suihkulokki: I think there are a few folks working on that already
<rsalveti> problem is that people got it all wrong at the beginning, it needs rework before being able to send anything upstream
<wookey> It looks a lot like what luke was trying to get done with PCMCIA-format A8, but only 1GB RAM :-(
<prpplague> wookey: yea it has some nice features and good size, but between lack of good mainline support and low amount of ram.....
<rsalveti> robclark: argh, worked fine with your config, need to check what caused the issue with the original one I used
<prpplague> rsalveti: have a fun trip back home?
<jimerickson> well omap4+armhf is working better than it did except for some wierd flashing in unity. why are fonts corrupted in the terminal in openbox?
<prpplague> jimerickson: because they hate you
<jimerickson> i thought as much!
#ubuntu-arm 2012-09-05
<robclark> rsalveti, XavB, fyi, I rebased my dispc-hl-split branch, and squashed in a few little fixes
<rsalveti> robclark: cool, will check that out
<prpplague> rsalveti: ping
<rsalveti> prpplague: pong
<prpplague> rsalveti: i am doing a quick informal survey of software developers, just one quick question: do you know the difference between asynchronous and synchronous communications?
<prpplague> rsalveti: hehe no googling
<XorA|gone> prpplague: hehe, trick question :-D
<prpplague> XorA|gone: hehe feel free to /msg me your response.... hehe
<rsalveti> prpplague: hahaha, sure :-)
 * XorA|gone has done
<prpplague> rsalveti: mind /msg your description of the two?
#ubuntu-arm 2012-09-06
<ogra_> http://www.indiegogo.com/dualdroidtv
<ogra_> ..."2GB of ram(because the future will come sooner than you think)"...
<ogra_> heh
<LetoThe2nd> ogra_: cotton candy clone?
<ogra_> dunno, whats a RK3066 ?
<suihkulokki> there is like a hundred of different android hdmi sticks these days
<LetoThe2nd> ogra_: its a "Richticher Komputer"
<ogra_> suihkulokki, this one has 2G and 16G flash
<ogra_> ah, rockchip
<suihkulokki> ogra_: it's unclear to me why they need $130000 for just asking a chinese manufacturer to make their usual batch with a bigger ram and nand chip :P
<ogra_> because they can ?
<LetoThe2nd> because "send us money for free" does not work nearly as well?
<wookey> I'm not sending money to people who can't spell 'piqued'
<xnox> wookey: I spell "piqued" can you send money to me please?
<xnox> ;-)
<slangasek> rsalveti: hey, I had a question about the licensing of pvr-omap4.  Can you confirm that the kernel driver itself is entirely GPL(-compatible)?
<rsalveti> slangasek: I can review it, but last time I did it was GPLv2
<slangasek> rsalveti: if you've already reviewed it, no need to re-review - thanks
<rsalveti> slangasek: MIT and GPLv2
<rsalveti> dual licensed
<slangasek> ok, great :)
<ogra_> rsalveti, hmm the new kernel doesnt wake up from DPMS properly anymore it seems
<ogra_> i can see the screen flicker when i switch with ctrl-alt-f1 ... ctrl-alt-f7 back and forth ... but neither X nor a console comes up
<ogra_> (the system was idling for a while and went into DPMS at the loin manager)
<ogra_> *login
<rsalveti> ogra_: hm, ok, will try to reproduce it here
<ogra_> i rebooted now ... somehow the panda also constantly changes its IP
<ogra_> so my ssh session died as well
<LetoThe2nd> ogra_: on that occasion, how do you work around the changing mac problem for testing?
<rsalveti> my screen was green when it was 'suspended', but got to the normal behavior after moving the cursor
<rsalveti> let me reboot and leave it there for a while
<rsalveti> worked fine as well when changing to c-a-f1
<ogra_> LetoThe2nd, fact is that it shouldnt change its mac
<LetoThe2nd> ogra_: do you pass it it via uboot, or what?
<ogra_> nope
<LetoThe2nd> then i personally do not see why it should keep the mac?
<ogra_> i havent seen it changing macs in quite a while actuallyx
<ogra_> in fact our bamboo-feeder relies on that and afaik it still works
<ogra_> what i see here though is that it renews the IP randomly
<LetoThe2nd> hm.
<robclark> rsalveti, fwiw, I built your kernel.. so far it seems to work ok on my end (well, x11/compiz started first time.. but that was still me starting lightdm manually)
<rsalveti> robclark: yeah, it's working most of the time now
<rsalveti> robclark: try restarting lightdm a couple of times
<rsalveti> to see if it'll always work
<rsalveti> robclark: also, if you let the screen to 'sleep' (DPMS), you'll probably get a green screen
<robclark> hmm..  it's the built-in screensaver :-P
<robclark> I do get the 'failed to enable GPIO' msg.. although so far doesn't seem to cause any problem
<rsalveti> brb
<robclark> rsalveti, hmm, is 'xset dpms force off' enough to trigger green for you?
<robclark> rsalveti, I suppose my .config probably differs from you.. this is what I'm using: http://hastebin.com/raw/votaraqalu
<rsalveti> robclark: yup, 'xset dpms force off' is already enough
<rsalveti> http://people.canonical.com/~rsalveti/quantal/kernel/
<rsalveti> the kernel I'm using
<robclark> hmm, also doesn't do it for me..
<rsalveti> let me compare with your config
<robclark> any chance you are using xrandr rotation?
<rsalveti> robclark: don't think so
<robclark> hmm, I had seen something like that w/ 2d buffers, but I can't even reproduce that now..
<robclark> (well, it was pink instead of green)
<rsalveti> robclark: http://hastebin.com/gudovoyamo.diff
<rsalveti> the diff between our configs
<robclark> hmm
<rsalveti> robclark: just saw that we're also using CONFIG_OMAP2_VRAM_SIZE=32
<rsalveti> robclark: don't think that's relevant anymore, right?
<robclark> yeah, you should be able to nuke that
<robclark> you might want to drop all the panel drivers too
<rsalveti> cool
<rsalveti> yeah
<rsalveti> robclark: and it seems I'm not able to reproduce the green screen all the time
<rsalveti> it worked a few times as expected, but I also got a white screen once
<robclark> hmm.. ok.. odd
<robclark> rsalveti, if you have debugfs enabled, snapshot /sys/kernel/debug/dri/0/ when it is in a bad state.. that should have a dispc registers dump
<rsalveti> robclark: cool, will see
#ubuntu-arm 2012-09-07
<TheMuso> /c/c
<ogra_> janimo, http://developer.nvidia.com/mobile/linux-tegra ... sadly no support for ABI 13
<ogra_> janimo, what do you think about a kernel backport to 12.04 ?
<ogra_> (then we could actually make use of that stuff)
<arakno> hallo pple
<arakno> is there any reason i cant chroot from armel into arm?
<ogra_> into arm ?
<arakno> yap
<arakno> i debootstrapped from arm
<arakno> but the platform is armel
<arakno> i know executables are compatible...
<arakno> s/from/an
<wookey> Does your kernel have OEABI support turned on?
<janimo> ogra_, so backport both of the nvidia-tegra and kernel packages to 12.04?
<janimo> sounds ok to me
<janimo> but is the current 12.04 buggy?
<janimo> what does rel16 fix ? It says full support for armhf but saw nothing more detailed on the site, and I did not check the release notes
<arakno> wookey: http://pastebin.com/q0Bij6Ch
<arakno> i guess you mean old eabi, but i am not cool enough to see it in my config
<arakno> so it is oabi
<arakno> maybe you can help me some other way
<arakno> i need to build a system on a binary for a project.  but the binary is linked against glibc_2.3. If i debootstrap etch, i get the libc not the chroot
<arakno> if i debootstrap squeeze i get the armel but run on higher and incompatible glibc
<ogra_> janimo, dunno, but everything is better than what 12.04 has now
<ogra_> the driver only works with the newer kernel though
<ogra_> (r16 tag)
<janimo> ogra_, no point in updating quantal though right?
<ogra_> janimo, not until they build for Xorg ABI 13
<lilstevie> ogra_, how do you build the deb for the nvidia-tegra driver
<lilstevie> cause I have the kernel, well almost have the kernel all done for the tf201 with r16
<ogra_> just pull the source and provide a new orig.tar.gz (and make sure the changelog version matches upstream)
<lilstevie> ah ok
<ogra_> oh, and make sure your orig,tar.gz has the same filesystem structure as the existing one
<lilstevie> yep sure
<lilstevie> I didn't notice that you actually had an orig.tar.gz I only saw the .deb
<ogra_> janimo, disabling CONFIG_VT_HW_CONSOLE_BINDING fixes the need for console= with 3.1, could you add change that in the next upload ?
<ogra_> -add
<janimo> ogra_, great! will do
<ogra_> seems marvin24 is also close to get r16 merged so probably a new git pull would make sense
<janimo> once he's done I'll rebase on that
<ogra_> (still 3.1 afaik)
<janimo> may be a good time to resync with some ubuntu configs, as people sometimes miss certain config options
<janimo> yes, 3.1.10
<ogra_> yup, we had one who complained about missin dvb drivers
<ogra_> (which are built on x86 ... havent cheked teh other arms)
<ogra_> janimo, ..."<marvin24> just pushed l4t-r16-ac100" ...
<janimo> ogra_, thanks
<janimo> marvin24, ^ tested and working fine?
#ubuntu-arm 2012-09-09
<daurnimator> has anyone here had luck getting audio capture going on their beagleboard?
<daurnimator> https://gist.github.com/a217a3d76dd550ba822b
<orated> Hello! I've installed Ubuntu 12.04 server image (http://cdimage.ubuntu.com/releases/12.04/release/ubuntu-12.04-preinstalled-server-armhf+omap.img.gz) on BeagleBoard XM C1. I've like to know how can I extend it to gui. I installed lubuntu-desktop package but tty7 is blank and it always boot to tty1
<orated> s/I've/I'd like to know*
<janimo> infinity, I found some mislicensed files in the armadaxp kernel. So we'll wait till there's a new upload, the current one can sit in the PPA only for now :)
<janimo> 'all rights reserved' as you suggested was the right pattern to search for
<orated> Hello! I've installed ubuntu-server image on BeagleBoard XM C1. I'd like to know how I can get gui. Installing lubuntu-desktop package is failing with blank screen on tty7 and booting always stop on tty1
<orated> And, what is the difference between arm-none-linux-gnueabi-gcc and gcc-arm-linux-gnueabi ?
<wookey> no real difference
<wookey> debian/buntu use 3-part triplets for compiler names. Others (upstream, code sourcery) often use 4-part 'triplets'
<wookey> the 'none' is nominally the vendor
<wookey> I'd guess your desktop isn;t working due to video device driver issues, but I've no idea which packages you need
<orated> wookey:  I've the following setup for display. BB > HDMI > HDMI to DVI-D adapter > DVI-D compatible monitor. I downloaded and install ubuntu-server image for ARM following Ubuntu ARM wiki page. On boot, on both serial terminal and monitor, I get tty1 login. Later, I installed lubuntu-desktop package and restarted, it still didn't work always reverting back to tty1.
<orated> Then, after installing xserver-video-omap3 pacakge(if I remember the name right), it behaved in same manner. Is there anything I'm missing?
<orated> Well lastly, how can I DSP support if I try ubuntu-desktop preinstalled images for ARM on BeagleBoard XM C1?
 * RoyK is using a standard Ubuntu Precise on his Pandaboard and it works ok
<orated> Hi RoyK, Is there a DSP on Pandaboard? Did you try anything which requires using DSP on the board?
<wookey> hmm orated left. Oh well
<piezo> does somebody know why "allow-hotplug" support is removed in ubuntu? (/etc/network/interfaces)
#ubuntu-arm 2013-09-02
<snkt> hello
<discopig> hi snkt
<hashken> Where do I find the repos for the ARM architecture
<hashken> Any repo I check, only has packages for amd64 or i386
<ogra_> ports.ubuntu.com
<hrw> hashken: there are rumours that when Ubuntu A+1 will be released then armhf will be in official repos
<hashken> Can I install these packages in raspbian for raspberry pi?
<ogra_> no
<ogra_> see the channel topic
<hrw> people still use r/pi?
<ogra_> sadly
<hashken> Oh sorry :)
<hashken> Raspbian repos are woefully inadeqaute
<hrw> hashken: r/pi is ubuntu incompatible
<hashken> Basically I want to install mininet in raspberry pi
<hrw> hashken: and nothing will change it
<ogra_> or debian/armhf incompatible :)
<hrw> is r/pi compatible with something at all?
<hrw> no Fedora, no Ubuntu, no OpenSuse, no Debian/armhf...
<hashken> But, it should be possible to compile the code to be arm compatible right?
<ogra_> it is compatible with raspbian :)
<ogra_> hashken, you need to recompile the packages and their deps against raspbian if you want to use them on the rpi
<hashken> Yeah, this is a lot of work :)
<hashken> By the way, the heading says Raspberry pi is compatible with Debian/armel
<ogra_> well, tell the rpi people to use a proper CPU next time :)
<ogra_> yeah
<ogra_> rpi works fine with old armel
<hashken> Do you know where I can find the repos for this?
<XorA> ogra_: you mean one they did not get for free on surplus market?
<ogra_> no, somewhere in debian
<ogra_> XorA, hehe, yeah
<hrw> XorA: ;D
<hrw> even people at ARM told Broadcom to not put arm11 into gpu...
<XorA> even my zx80 is more useful than a Pi
<hrw> XorA: for sure
<hrw> XorA: but original one or zx80core one?
<XorA> hrw: I have both
<XorA> hrw: although I need to populate the zx80core
<XorA> wonder if I can fit a arm2 emulator in 16k of ram ;-)
<hrw> XorA: 16K? rich one
<XorA> hrw: got a few 16k RAM packs lying around
<aryans> CAN anyone help IOMMU page fault on Snapdragon architecture
<doomlord> does ubuntu arm run on the new nexus7 :)
<ogra_> the userspace surely does ... for kernel and bootloader setup as well as installation you have to take care yourself
<kulve> any alsa gurus here? I'm trying to configure alsa on Ouya but I can only get half speed audio on the left speaker..
<prpplague> infinity: greetings
<kulve> alsactl: set_control:1464: Cannot write control '2:0:0:HDA Maximum PCM Channels:0' : Operation not permitted
<kulve> any idea what might be causing that?
<Tassadar> Is there, by any chance, a person whom this github account belongs to? https://github.com/EnJens
#ubuntu-arm 2013-09-03
<aryans> Someone knows about IOMMU fault .
<aryans> Why this fault occurs
<snkt> hello everyone
<Sonicadvance1> Good morning
#ubuntu-arm 2013-09-04
<snkt> hiii
<Sonicadvance1> oh hai mark
<snkt> how to create a oneiric armel toolchain on host 13.04 machine
<hrw> snkt: oneiric? it is not supported. upgrade that machine to precise
#ubuntu-arm 2013-09-05
<ad-n770> hi, I've got an old device some sort of lenovo netbook with freescale i.MX51 SoC running ubuntu 9.04
<ad-n770> do you know how to update it at least into ubuntu 10.04 ?
<ad-n770> I've written an SD card with ubuntu-10.04-netbook-armel+imx51.img
<ad-n770> but it doesn't seems to boot it when inserted in the built in SD slot
<ad-n770> it seems there's a redboot bootloader in the system but I don't know how to get access to it
<ad-n770> would be safe just change in /etc/apt/sources.list jaunty for lucid and apt-get update + apt-get dist-upgrade ?
<thefunc5> what happens when you run sudo apt-get dist-upgrade?
<thefunc5> i forgot the command but you can list if there is a distro upgrade available
<ad-n770> well it says download about 1k pakages
<ad-n770> 1075 upgraded
<ad-n770> 345 newly installed
<ad-n770> 41 to remove
<ad-n770> an 0 not upgraded
<thefunc5> that sounds alright
<thefunc5> i would do it, but not many of my systems are business critical
<ad-n770> ok, I'll give a try
<ad-n770> but I'm wondering where kernel/initfs is in that system
<ad-n770> maybe there's something else I need to update, I've seen in dmesg about four partitions in a mmc like storage
<ad-n770> I think one was labeled redboot and another one kernel
<ad-n770> damn, things doesn't go smooth, post-installation script of libc6 segmented
<ad-n770> well seems I've probably broken it
<ad-n770> ideas ?
<hrw> ad-n770: userspace can be updated even to 13.04. the problem may be with old kernel
<ad-n770> any procedure suggested to unbrick it ?
<hrw> ad-n770: get to bootloader, boot other system image?
<ogra_> hrw, jaunty armel was just "debian rebuild in the ubuntu infarstructure" ... from karmic on it was VFP, ARMv6 etc etc ... it can well be the new libc incompatible uses instructions
<ogra_> *uses incompatible instructions
<hrw> ogra_: imx51 should be able to use it anywya
<ogra_> hrw, but probably not the installed system :)
<hrw> mx51 is slow as hell anyway
<ad-n770> mmm, behind the battery I've found more card reader slots
<ogra_> yeah, cortex-a8 isnt really for desktops
<hrw> ad-n770: can you share a photo of device?
<ad-n770> it's a black  netbook with lenovo text on the screen
 * ogra_ guesses it has genesi printed on the lid
<ogra_> oh
<hrw> ad-n770: photo please
<ad-n770> give me a sec
<hrw> I may guess that it is yet another pegatron clone like efikamx
<ogra_> anyway, a) you would need to upgrade from jaunty via karmic, going straight to lucid wouldnt work ...
<ogra_> and b) the ABI changed massively between jaunty and lucid
<ad-n770> https://www.dropbox.com/s/bgy9ykc1tn0p5sb/photo%20%281%29.JPG
<ad-n770> lenovo written in the screen
<ad-n770> plug for power, phones and SD card on left
<ad-n770> two usb and an empty hole at right side
<ad-n770> with battery removed I've found what seems a micro SD slot and another slot I can't identify
<hrw> yet another pegatron ;)
<hrw> ad-n770: its sim slot
<hrw> ad-n770: find instructions for efikamx smartbook and follow
<ad-n770> now it's just bricked, I read "input: pegatron kunlun extra buttons"
<hrw> ad-n770: it is not
<hrw> ad-n770: it just look that way
<hrw> http://marcin.juszkiewicz.com.pl/2012/02/01/flashing-u-boot-on-efika-mx-smartbook/ is one post to help
<ad-n770> reading it now
<hrw> ad-n770: http://www.powerdeveloper.org/forums/ may also help
<hrw> ad-n770: join #efika channel as well
<hrw> ad-n770: or just put it into box with "electrotrashes" sign on it
<ad-n770> I will try to recover it
<smartboyhw> ogra_, BTW: You are responsible for http://iso.qa.ubuntu.com/qatracker/milestones/302/builds/52690/testcases right?
<smartboyhw> Since phillw resigned from his QA Lead role, I thought it might be a good idea to remind you of it
<ogra_> smartboyhw, i'll try to find some time for testing the final image
<prpplague> infinity: ping
#ubuntu-arm 2013-09-06
<snkt> hiii
<Sonicadvance1> Good morning
<snkt> I m using ubuntu core 11.10 for ARM... I m facing issue on usb printer...
<snkt> Epson printer
<hrw> snkt: update to 12.04 please to get supported release
<hrw> snkt: and which printer model?
<snkt> hrw, i am using EPSON - LX300+
<hrw> snkt: does it work for you with x86 box?
<snkt> yes it is...
<snkt> when I insert "usblp" module and I fire "lpinfo -v"
<snkt> it doesnot show the entry
<snkt> network http
<snkt> network ipp
<snkt> network lpd
<snkt> serial serial:/dev/ttyS0?baud=115200
<snkt> serial serial:/dev/ttyS1?baud=115200
<snkt> serial serial:/dev/ttyS2?baud=115200
<snkt> serial serial:/dev/ttyS3?baud=115200
<hrw> usblp should be autoloaded on cable insert
<snkt> but if I remove usblp module
<snkt> lpinfo -v gives
<snkt> network ipp
<snkt> network http
<snkt> network lpd
<snkt> serial serial:/dev/ttyS0?baud=115200
<snkt> serial serial:/dev/ttyS1?baud=115200
<snkt> serial serial:/dev/ttyS2?baud=115200
<snkt> serial serial:/dev/ttyS3?baud=115200
<snkt> direct usb://EPSON/LX-300+?serial=L04011104121645120
<hrw> so you have it visible
<hrw> setup cups and go?
<snkt> ya i m using cups
<snkt> I think might be an issue of udev rule
<snkt> ??
<snkt> https://bbs.archlinux.org/viewtopic.php?id=126419
<snkt> https://bbs.archlinux.org/viewtopic.php?pid=1318194
<hrw> snkt: if lpinfo prints 'direct usb://' then it see printer
<snkt> but in that case it doesnot create /dev/lp0 device
<hrw> it does /dev/usb/lp0 probably
<snkt> If I insert usblp module then it create the device node...
<snkt> but in that case lpinfo -v doesnot show the printer
<hrw> no idea man
<pagios> hi all
<pagios> http://apaste.info/34Il
<pagios> i am having problem getting php and apache working on my arm
<pagios> http://apaste.info/NXJJ
<pagios> damn..........
<pagios> http://pastebin.com/jbtfaBn8
#ubuntu-arm 2014-09-01
<marvin24> ppisati: seen https://launchpadlibrarian.net/183544214/buildlog_ubuntu-utopic-armhf.debian-installer_20101020ubuntu339_FAILEDTOBUILD.txt.gz ?
<marvin24> actually, the device tree isn't packed into the kernel-image anymore
<ppisati> it was moved to /boot/$(uname -r)
<ppisati> but there's a symlink from /boot/$(uname -r) to /lib/firmware/$(uname -r)
<ppisati> so it shouldnt happen
<ppisati> hold on
<marvin24> ppisati: btw, you silently assume that the filesystem understands symlinks (some people still use fat for /boot partition)
<marvin24> even worse, you assume the bootloader understands symlinks (which is not the case for u-boot)
<marvin24> but that's a different problem
<ppisati> ???
<ppisati> yes it does
<ppisati> i tested it
<marvin24> which version?
<ppisati> the utopic version
<marvin24> of uboot?
<ppisati> yes
 * marvin24 didn't know that there is something like this
<marvin24> uboot shouldn't be updated with the distro I think
<ppisati> in fact
<ppisati> the symlink is there just for flash-kernel
<ppisati> uhm
<ppisati> btw
<ppisati> when you install a new kernel, flash-kernel is still run
<ppisati> so if you don't modify your boot script
<ppisati> nothing changes
<ppisati> here is something completely different
<marvin24> ppisati: well, I would be happy to be able to install a kernel :-)
<marvin24> first the installer needs to be fixed
<marvin24> I also have another question regard this (how the installer selects the kernel flavour), but this can also wait
<ppisati> marvin24: i sent a revert for that patchset, i'll send a v2 and cc: you so you can raise your questions there
<marvin24> ppisati: thanks
<marvin24> I used the utopic installer on my tegra netbook
<marvin24> everything went fine until it came to the kernel install
<marvin24> there it says, can't find kernel flavour to install or something like this
<marvin24> I guess there must be some hw detection which decides which flavour to use
<marvin24> can you point me to some more infomation?
<marvin24> I mean this one (with updated kernel) http://ports.ubuntu.com/ubuntu-ports/dists/utopic/main/installer-armhf/current/images/generic/netboot/tegra/
<ppisati> honestly i don't know the installer enough
<ppisati> infinity: maybe he knows the answer ^
<ppisati> ogra_: or him ^
<infinity> marvin24: Yeah, libdebian-installer (and some other bits) need to know how to detect your system, though we really should switch it to just defaulting to "generic" for anything it can't detect, and wing it.
<marvin24> infinity: yes, generic would be nice (and the right one for me)
#ubuntu-arm 2014-09-02
<lool> win 35
<lool> ups
<n3rd_dude> hello, I've got lubuntu running on a marsboard (Allwinner A10) and I have the option to update 12.04 to 14.04
<n3rd_dude> should I proceed?
<n3rd_dude> the reason I'm considering this is, a couple of issues like gpu driver and the fact that I use archlinux with newer tools, will updating be worth it?
<n3rd_dude> will it even work?
#ubuntu-arm 2014-09-03
<Netham46> I've got an ARM box (First-gen CuBox), and the only ubuntu distro I can find is an ubuntu 12.10 image
<Netham46> It looks like the package repos for it are down
<Netham46> Is there an alternate mirror for older ARM releases?
<Netham46> I'm looking to do a dist upgrade to bring it up to date, but I can't get it fully installed in the first place w/o the repos.
<Netham45> Nevermind, found it at http://old-releases.ubuntu.com/ubuntu/ .
<nikko_01> hello. I have not used my pandaboard in a year and was wondering if anyone had an idea how it would perform with 14.04
<infinity> nikko_01: Headless or desktop?
<infinity> nikko_01: As a headless machine, they still perform really well, and are quite handy.
<infinity> nikko_01: For desktop/gui type use, the situation's a bit crap, cause TI dropped support on the floor for OMAP4 quite a long while back, which means no more sketchy binary drivers which means no more 3D drivers at all, since there isn't an open source powervr driver.
<nikko_01> infinity: so the situation has not changed. I did want to use it to build my UI as well as real-time embedded processor.
<infinity> nikko_01: So, you can run a desktop that doesn't demand fancy 3D performance (xubuntu, lubuntu, etc), the 2D framebuffer performance isn't awful, but no 3D and, more importantly for some usecases (set top box?), no non-free video decode acceleration.
<infinity> nikko_01: The situation isn't likely to improve ever, really.  PowerVR doesn't play well with others.
<nikko_01> infinity: Got it. It's a shame .  I have 2 of those boards. I assume the same is true with beagleboard Xm?
<infinity> Not sure that video's on the XM, or the state thereof.
<nikko_01> I tink it is the same chip or earlier generation if I am not mistaken
<infinity> But pretty much anything who's upstream status is "nothing but a non-free driver", we're not shipping any of those, and for most of them, it's because it's usually an unsupported non-free driver that only works with a kernel from 4 years ago.
<nikko_01> Infinity: Thanks for the info. Any arm board in those price ranges you know of?
<infinity> Haven't kept track of the latest and greatest.
<infinity> But free Mali drivers are starting to not suck, AFAIK, so in the future, I'd look for SoCs with Mali GPUs.
<nikko_01> ok. thanks for the info again.
<infinity> Though, today, unless you're really into hacking together stuff and playing a LOT, pretty much everything sucks.
<infinity> Except if you take a device that you know works with, say, Android or ChromeOS, and violently shoehorn their drivers and kernel into Ubuntu.
<infinity> Which is actually a lot less fun than it sounds.
<infinity> I don't recommend it.
<nikko_01> does not sound like fun
#ubuntu-arm 2014-09-04
<ndec_> hi ogra_, i think i might have asked you already... but how to you setup adbd in ubuntu touch? the adbd daemon from the archive is working fine on my board, but i need to do some configs in /sys/class/android_usb first and I am not sure where i should be doing that.
<ogra_> well, android should do that for you
<ndec_> ogra_: i am not using android..
<ogra_> we are relying on init.rc to set up all the defaults in the container before we fire up the adbd on ubuntu
<ndec_> ok, i see.
#ubuntu-arm 2015-09-02
<schuschu2> not sure if i'm in the correct channel but http://ubuntu-cloud.archive.canonical.com/ubuntu/ has missing armhf packages (so far i only found python-cryptography) which only has a arm64 package...
<rbasak> schuschu2: you can report a bug from https://launchpad.net/cloud-archive
<ogra_> schuschu2, not sure what that is ... debs are usually on ports.ubuntu.com/ubuntu-ports ...
<ogra_> and looking under http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/$dist/* i see a bunch of Contents.gz files for armhf too
<rbasak> ogra_: it's Openstack backported to the LTS, maintained by the server team
<schuschu2> yes some packages are missing which is the strange part
<ogra_> schuschu2, well, rbasak is clearly the cloud specialist here ... file a bug ... (i'm nly guessing anyway ..)
<ogra_> *only
<rbasak> schuschu2: it might well have just failed to build on a particular architecture, which is valid as a bug but probably not a priority. A bug would be the best place to report it (please include standard bug report detail etc) and track the issue.
<rbasak> schuschu2: please also state your openstack use case - the cloud archive is supported for openstack only
<schuschu2> rbask: i'm currently in the process of raping two rpi2s to function as a makeshift cluster.... my guess was kilo is as good a start as anything else
<schuschu2> rbasak: sorry for the type in your name ....
<rbasak> schuschu2: if this is an experiment rather than for production use, you might be better off using Vivid or even Wily rather than the cloud archive. You're more likely to get fixed stuff that way.
<rbasak> schuschu2: and anything you fix yourself will be easier to send upstream and adopt
<infinity> python-cryptography builds on all arches in vivid and wily.  If there's a cloud backport where it doesn't build, the bug is there.
<infinity> rbasak: Where do actual cloud archive backports build?  I assume a PPA somewhere.
<rbasak> infinity: yeah, a PPA somewhere. I don't know which without digging, sorry.
<infinity> Ahh, found it.
<infinity> And the staging PPA only has x86, so no, maybe I didn't find it. :P
#ubuntu-arm 2015-09-04
<jayfly> Hello there what is the mirrors url for armhf boards for security ?  for debootstrap.
<infinity> jayfly: http://ports.ubuntu.com/ubuntu-ports
<jayfly> infinity:  so  there is no secutiy url  for surces list like debian ?
<jayfly> Like after I run second-stage and use qemu-arm-static.  then alter sources.list.
<jayfly> via chroot
<infinity> jayfly: We publish security to the main archive too.  The only reason we *also* provide a security.ubuntu.com is if you're using a mirror that updates slowly, our security mirror is always up to date.
<infinity> jayfly: But that doesn't matter for ports, since it's always up to date too, and no one mirrors it. :P
<jayfly> sweet thanks a bunch !!
<infinity> jayfly: (You want wily-security in your sources.list, of course, but it can be from the same ports.u.c)
<infinity> And wily-updates
<jayfly> my web app builds for all the odroids and pi's having a lot of fun with it.
<infinity> s/wily/trusty/ or whatever you're using.
<jayfly> got it
<jayfly> I will just right a case statment to say hey if ubuntu just add the main urll
<jayfly> url *
<infinity> jayfly: If the above was unclear, it should look something like this:
<infinity> http://paste.ubuntu.com/12276398/
<infinity> jayfly: And you can get away with the same trick for x86 too, if you use Canonical mirrors (archive.ubuntu.com), but if you use non-Canonical mirrors (TLD.archive.ubuntu.com or other), then you want security.u.c for security, because mirrors aren't guaranteed to be up to the minute.
<jayfly> that is what I was looking for thanks again    trusty-security
<jayfly> thanks again infinity  :)
<jayfly> now I can add Ubuntu to the autobuilder's nice webinterface
<jayfly> lol pixz keeps on overheating my crappy computer lol.  I should check the arch and mem
<infinity> jayfly: FWIW, the reason Debian needs to have a security mirror and we don't really is because Debian's ftpmaster only publishes once or twice a day (and pushes to mirrors), while security.debian.org publishes instantly whenever the security team pushes an update.  So, if you had to wait for ftpmaster, you might be a sad panda.
<infinity> jayfly: In Ubuntu, we just publish the whole lot every 15m or so, but only push to non-Canonical mirrors every 4h.
<jayfly> No one likes sad panda's
<jayfly> well maybe panda hunters but not sure that most people like them
<jayfly> whoa every 15 minutes that is great !!
<infinity> Great, or insane, take your pick.
<infinity> Despite being one of the people behind that, I'm never quite sure if it's crazy. ;)
<jayfly> I will go 51-50 on that one
<infinity> But it works for us.  You can also understand why we limit how often we push that outside our network. :P
<infinity> Mirror operators would strangle us if we triggered them every 15m.
<jayfly> infinity:  sometimes debian mirror gives me 404 and build fails half way between stage two of debootstrap.  I should just bite the bullet get some TB drives and clone mirror
<jayfly> but I think my network can not handle
<infinity> Some mirrors are certainly more reliable than others.
<infinity> And if you're using a round-robin DNS alias, you might get screwed if you're in the middle of a push, cause you get Packages from mirror A, and the /pool/ of mirror B.
 * jayfly afk 5 minutes to look for fan to put next to autobuilder on this hot day in CA 
<infinity> Usually best to pick a specific reliable mirror that's near you and just abuse that one.
 * jayfly back 
<jayfly>  /join #odroid
#ubuntu-arm 2016-09-08
<pcmc2a> hello
<guideX> how well does it work on the raspberry pi zero
<TheMuso> guideX: How well does what work? Either way,t eh Rasperry Pi 0 is not supported by Ubuntu.
<lilstevie> TheMuso long time no see
<zzarr> hello!
<zzarr> can I some how create a user and set a password for the user in a system image for arm from a x86_64 system?
<Krulz> hi
<Krulz> i want to install MariaDB, i have a android chroot running on a armv7, can someone tell me how i chance the next command for my architecture?
<Krulz> sudo add-apt-repository 'deb [arch=amd64,i386] http://mirror.i3d.net/pub/mariadb/repo/10.1/debian wheezy main'
<ogra_> how about you ask in a debian channel ?
<ogra_> (given you try to use debian archives ... so i assume you have a debian system running ? )
<Krulz> yes
<k1l> and with arch=amd64,i386 its not going to work on arm at all
<Krulz> well that was my qeustion :)
<Krulz>  == Krulz was kicked from #debian-arm by ChanServ [Invite only channel]
<Krulz> :(
<iztok-jeras> Hi, I am working on an ARM board without a GPU, but I have a framebuffer device attached to it. I have ubuntu-base-16.04.01 installed. I would like to know how to start X on boot automatically
<guideX> TheMuso: ah ok
<guideX> well that settles that lol
<guideX> is it a matter of time before the pi zero is supported?
<guideX> or just never will be
#ubuntu-arm 2016-09-11
<expert> hi all
<expert> could somebody help me with installing Linux/Ubuntu on an Android TV Box (running ARM processor) that does not have an sdcard, only internal memory?
