#ubuntu-arm 2009-08-03
<Ford_Prefect> Anyone tried booting a rootstock generate rootfs with NFS?
<Ford_Prefect> The dratted NM seems to be pulling down the network for a restart, which breaks because it's running from NFS
<lool> Ford_Prefect: Right there's a bug with NM breaking network on NFS (that's not related to rootstock I think)
<lool> I've seen it filed on Debian it's probably reported in Ubuntu as well
<Ford_Prefect> lool, ah, okay. I worked around it by putting an exit in /etc/default/NetworkManager
<lool> Ford_Prefect: eh I guess that works
<lool> I seem to recall that one issue was that there was some chicken and egg issue with /usr needed for NM to start and NM being needed to get /usr from NFS
<lool> But then in your case what you really want is for NM to start without touching the network
<Ford_Prefect> lool, it's a pretty hard problem to crack in a please-all way, I guess.
<lool> Ford_Prefect: Yeah exactly
<lool> Ford_Prefect: That said, your bug would probably be fixed if NM was careful not to wipe clean the network config when starting up to replace it with its own
<Ford_Prefect> Guess it would be a little hard to make sure that no network access is required between when NM starts touching the config and when it finishes setup
<lbt> anyone familar with dpkg-cross. I'm hitting issues with -dcv1 vs -cross  how do I make -dcv1 packages?
<lool> lbt: We're building our own or using the codesourcery ones
<lbt> so I'm approaching this by setting debian/target=armel and then debian/rules control to make a gcc-cross.
<lbt> is that you mean by "building our own"?
<lool> lbt: Install binutils-source or grab the source yourself, same for gcc and build these
<lbt> OK. I want to integrate this into the OBS build system - building from source is fairly simple. I'd like to track the gcc as shipped by ubuntu so we have version match
<lbt> I'll check out emdebian though - thanks  for that :)
<lool> lbt: Note that I'm not making a recommendation of emdebian, but the tools you mention are emdebian ones so they are the people who can help you use them
<lool> (IOW I don't use them myself)
<lbt> that's fair... NB my objective is to produce a cross compiler to install (elegantly) into a qemu chroot
<lbt> I would like to base it on gcc.dsc
<lbt> so as gcc evolves with Jaunty/Karmic
<lbt> I can update my chroot build env to match
<lbt> currently dpkg-cross seems a viable way to do it using debuild...
<rjune_> lbt: I use crosstool-ng to build for our platform. Though we're building a complete distro, not just building for debian or ubuntu
<lbt> rjune_: My objective is a drop-in replacement for gcc_XXX_armel in a qemu-chroot
<lbt> s/drop-in/kinda drop-in/
<rjune_> then crosstool probably isn't for you, did emdebian prove helpful?
<lbt> I've not brought it up yet.... I actually found a maybe solution
<lbt> waiting for my turn in the build sched
<lbt> ooh... finished but not finalised....
<lool> Hmm I don't remember finding crosstools-ng last time I was looking for such stuff
<lool> Seems nice
#ubuntu-arm 2009-08-04
<kedars> I built an RFS using debootstrap. I have been incrementally adding packages to the same using apt-get install. Now I have ended up in a situation where I cannot quite change the password of any user.
<kedars> doing that gives me an error "Authentication token manipulation error"
<kedars> I have already done "pwconv" and my root user can login properly into the system
<kedars> but when I try to chagne the passwd for any user this message comes up
<kedars> probably, i. I need to install something else? pam-something? or try another command analogous to pwconv?
<Stskeeps> kedars, check your system time
<Stskeeps> and make sure it's correct
 * kedars checks
<kedars> cool, the time was old alright, and setting it to current and re-creating the user worked :) thanks Stskeeps!
<Stskeeps> np - we had same issue
<Opti-Spaguetti> hello
#ubuntu-arm 2009-08-05
<Q_Continuum> Anyone happen to have a apt-mirror config file for an ARM repo mirror?
<Q_Continuum> I have a Marvel SheevaPlug on it's way, and I wanted to start getting a mirror set up, as I'll be on limited 'net for the first week I have the device and want to putz with it.
<kedars> I am creating an RFS by chrooting into it. When I install anything like sshd etc. then by-default that services starts in the chrooted RFS itself.
<kedars> Thus I cannot umount /dev /proc and other directories from the chroot
<kedars> is there any apt-get option where I can specify don't start these daemons etc.?
<lool> Q_Continuum: Sorry I don't have one but if you have any Ubuntu one you can just replace archive.ubuntu.com/ubuntu with ports.ubuntu.com/ubuntu-ports
<lool> arch is armel, you want jaunty and/or karmic dists
<lool> Or series rather
<beyossi> hi,
<beyossi> anybody is familiar with: "sudo: must be setuid root" issue?, most of the forums discussions are about desktop environments where installation cd may be in use. i can't realy use my  board without sudo ...
#ubuntu-arm 2009-08-06
<kedars> isn't mplayer available for arm? apt-get install mplayer doesn't work
<kedars> "Package mplayer is not available, but is referred to by another package.
<kedars> This may mean that the package is missing, has been obsoleted, or
<kedars> is only available from another source
<kedars> "
<kblin> kedars: aptitude search mplayer doesn't show it, so I guess it's not built
<lool> kedars_: It seems to be failing to build in libmpeg2 right now which shouldn't be too hard to fix as I think mpeg2dec is building fine on armel
<lool> libmpeg2/motion_comp_arm_s.S: Assembler messages:
<lool> libmpeg2/motion_comp_arm_s.S:29: Error: selected processor does not support `pld [r1]'
<lool> kedars_: Mind filing a bug and sub-in the ubuntu-armel team?
<lool> Yeah mpeg2dec built fine
<kedars_> lool: is this build system available openly somewhere I can look at?
<kedars_> lool: also now that the mpeg2dec is built, is there a known time delay after which  I can get to install mplayer?
<lool> kedars_: Hmm good point -- you don't have any armel hardware to build it on?
<lool> kedars: The mplayer source in Ubuntu contains a fork of libmpeg2 which is failing to build
<lool> mpeg2dec is the canonical upstream source for libmpeg2 and does build
<lool> So either new mplayer changes are breaking it or the mplayer copy is out of date (probably the former)
<kedars> lool: ok. I can build it on local hardware, could you please point me to the sources?
<lool> kedars: apt-get source mplayer!
<lool> kedars: http://archive.ubuntu.com/ubuntu/pool/multiverse/m/mplayer/mplayer_1.0~rc3+svn20090426-1ubuntu4.dsc
<kedars> lool: cool, thanks!
<thebishop> hello
<thebishop> is there a better channel for general ARM discussion?  I'm looking for discussion of the ZiiLabs/Creative ZMS-05
#ubuntu-arm 2009-08-07
<zhangxing> how can we use the jlink program norflash under linux system??
<lool> What's jlink?
<zhangxing> JLINK
<zhangxing> segger company's JTAG tool
<lool> openocd seems to know about it
<lool> zhangxing: Are you using openocd?
<zhangxing> a usb jtag
<lool> I don't know whether the jlink program works under Ubuntu, it's not packaged in Ubuntu at least, but openocd might be able to use your cable
<zhangxing> no, I just start to use the JLINK and my laptop hasn't the parallel port
<zhangxing> I can use the JLINK for linux to connect the target board but I dont konw how to program the norflash with it
<zhangxing> because there is a jlink tool --JFLASH ARM  which can program the norflash easily
 * zhangxing waiting for your help...........how to use JLINK to program norflash under ubuntu system 
<kblin> zhangxing: the same as on other linux systems, I guess
<zhangxing> but there isn't the jlink flash software
<kblin> well, it seems like this is a windows-only piece of software
<zhangxing> yep , and only using it we can program the norflash, and I don't know how to program norflash under linux
<zhangxing> use some jlink command ??
<PumaX> kimse yok mu ?
#ubuntu-arm 2009-08-08
<Q_Continuum> Is there any way to emulate an ARM CPU on an Ubuntu i386 host?
<kblin> hi folks
<kblin> I seem to be having some issues with the usb otg port on my beagleboard. it seems like the 2.6.29 kernel has problems loading the driver
<kblin> any clues on how to debug this?
<kblin> is there anything I can do test-wise to help getting the beagleboard supported by ubuntu? I keep running into issues I'd be happy to help fixing, but I'm not sure where to get started
#ubuntu-arm 2010-08-09
<hrw> morning
<lag> sebjan: Ping
<cooloney> lag: sebjan is away on vacation i think.
<lag> cooloney: When do we get TIs patches
<cooloney> lag: i didn't get it yet
<cooloney> lag: i will ping them today
<lag> I'm happy to do it
<lag> How do they normally send them to you?
<cooloney> normally, sebjan will prepare the branch in their integration tree
<cooloney> and ask me to pull
<cooloney> but i think this time ndec will help to do that
<lag> cooloney: Let me know if you want me to take care of it
<cooloney> lag: no problem, man. just send out an email to ndec and added you in
<lag> I received it
<rsalveti> lag: did you get the new TI release?
<lag> rsalveti: Nothing yet
<lag> Perhaps ndec will know more?
<ndec> lag: hi. sorry I am not too responsive these days...
<ndec> lag: many people on vacations, too many things to cover ;-)
<lag> ndec: Do you think they will be done sometime this week?
<ndec> lag: i have seen cooloney email. i received the new BSP based on .35, but I haven't had time to look into it.
<lag> ndec: We have a few users (and developers) who are struggling with a few things we're waiting for bugs for
<lag> bug fixes*
<ndec> lag: this branch: http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.9 has the latest BSP, but it does not support panda yet, only blaze.
<lag> Panda is the key one for us
<ndec> lag: i am planning to have a branch with this .35 OMAP4 BSP + ubuntu patches + panda sometimes this week.
<lag> ndec: Thanks
<lag> rsalveti: There's your answer :)
<ndec> rsalveti: hi... does it answer your question?
<rsalveti> lag: ndec: yep, thanks :-)
<dyfet> I found a simple armel ftbfs much earlier this morning...libgd2
<asac> dyfet: have a fix? ;)(
<asac> or you mean "found a fix" ;)
<dyfet> yes
<asac> dyfet: if you want a sponsor at best file a bug attach the debdiff and let me or ogra know
<dyfet> I have to go back to the doctor this morning, but it was a quick one to fix, so i am going to do that shortly
<ogra> libgd2 ? doesnt that need a fix in libc ?
<ogra> iirc it fails on the wrong dh_shlibs setting currently
<asac> ogra: dunno. didnt look at the build failure ... ;)
<ogra> i think it was the one
 * asac goes looking
<ogra> it looked like a bug in dh_shlibs
<asac> yeah feels like it
<ogra> but it turned out that glibc provides broken info to dh_shlibs
<asac> yes, if libc still mentions not existing package then thats the case
<asac> but maybe dyfet managed to not use that part at all ;)
<ogra> so its effectively a glibc bug, only if we cant fix it there in time we should add a hack, else just wait
<asac> (which wouldnt be that bad either ... of course libc needs to be fixed)
<ogra> right, if he has a better fix thats indeed better :)
<asac> right
<asac> ogra: and he should open a bug for the libc issue if its not reported and make it release critical so doko actually fixes it ;)
<ogra> i think its open upstream or in debian somewhere, i dont have the bug #'s here atm
<ogra> we added the hack in karmic already (same issue back then)
<ogra> bah, sigh, i just bought a new car ... only thing it needs are new tires .... and i just looked up the tire price for that size of tires ... seems thats additional 10% of the price of the car ... sigh
<markos_> ogra: are you referring to the ld-linux3-dev override hack in d-shlibmove for libgd2?
<ogra> markos_, xactly
<markos_> if so, I found more packages with exactly the same problem -well, the debian ones, but I guess it might still be valid for ubuntu
<markos_> namely ghostscript, graphviz and jbig2dec (plus libgd2 ofc)
<ogra> yeah
<lag> mpoirier: Works for me
<ogra> we had probs with all these back in karmic and changing the ld-linux3-dev entry fixed all of them
<markos_> fixed it in glibc?
<mpoirier> lag: fantascit - I'll wait 'till GrueMaster has a chance to test it too.
<ogra> no, in dh-slibs
<markos_> oh, right, but the maintainer in debian opposes the change
<ogra> which is right
<GrueMaster_> mpoirier: I'll try to get to it sometime today.  I'm in the middle of a Lucid>Maverick upgrade test atm.
<mpoirier> GrueMaster: that would be great.
<markos_> well, I used a simple "fix" in the same packages, I just added an override in each package, though the best solution would be ofc to fix glibc
<mpoirier> GrueMaster:  I'll push the change in when you confirm it works for your.
<amitk> anybody know how to "resume" booting after one has been dropped to the initramfs shell?
<ogra> amitk, ctrl-d
<ogra> though if you are past a script thats essential and it doesnt get re-executed it might fail
<amitk> ogra: it does :-/ with "chvt: can't open console"
<ogra> that sounds more like a devtmpfs or udev prob
<ogra> do you have devtmpfs compiled in ?
<ogra> and is udevd running
<lag> ogra: If I have a kernel and I run update-initramfs on it them mkimage it, should it just work?
<ogra> lag, if you wait until my just uploaded initramfs-tools is in the archive you only need update-initramfs
<ogra> no mkimage or anyrthing needed ;)
<lag> So what's this for then:
<lag> mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d ./initrd.img-* ./uInitrd
<ogra> that will give you a uImage in $(pwd)
<lag> A uImage?
<lag> Not a uInitrd?
<lag> ogra: ?
<ogra> lag, err, indeed, uInitrd
<lag> And that's what I want right?
<ogra> no idea what you want
<ogra> what do you plan to do ?
<ogra> lag, if you want to actually use it, it needs to be copied into the vfat partition too
<lag> ogra: http://paste.ubuntu.com/475518/
<lag> This is what I'm doing
<lag> Is it correct
<rsavoye> any ideas for a stable kernel I can run on an XM board that seems to trigger segfaults ?
<lag> ogra: Line 67-71
<ogra> lag, yeah
<lag> rsalveti: Would you mind rephrasing the question please?
<lag> Hmmm
<rsalveti> lag: rsavoye :-)
<ogra> rsavoye, there are bad ram chips on a good bunch of the XMs
<rsavoye> is that my problem ? I can;t compile anything
<ogra> rsavoye, if you have one of these, no kernel wont help
<rsavoye> arg.... so much for free hardware :-(
<ogra> i dont know exactly how to tell them apart
<lag> rsalveti: :)
<rsavoye> I'd love to know, it's getting in the way of work...
<ogra> but there are two different manufacturers for the ram
<ogra> one works, the other doesnt
<rsavoye> Mine's got an 'A' on it
<lag> rsavoye: I think it will only affect you if you are using >255.9MB RAM
<rsavoye> I've got 512M, can I limit it to 256 but at 1Ghz ?
<ogra> which he likely does when compiling
<ogra> you could try booting with mem=
<rsavoye> I'm using micheal1's C4, but now there are two of trying to compile at the same time...
<ogra> well, XM is pre-production HW, dont expect it to work flawless yet
<rsavoye> this was supposedly post production... :-(
<rsavoye> ogra: how to boot with mem= from the monitor ?
<ogra> there are no "post production" XMs yet
<rsavoye> ah....
<ogra> you need to change the cmdline in boot.scr (if your image has one, no idea what you use over there)
<ogra> else you are doomed to serial console :)
<rsavoye> I can live in the serial console no problem if it stops crashing :-)
<ogra> just for setting the mem= option i mean :)
<rsavoye> that's what I was going to try, just gotta figure out the command line
<ogra> in ubuntu the source for boot.scr is stored in /boot/boot.script, you can just change it and run sudo flash-kernel and reboot, not sure how it is on the linaro images
<rsavoye> I should be running stock maverick
<ogra> stock maverick from one of the alpha releases ? that should work with the ubuntu method above
<rsavoye> yes, alpha-2 I believe
<lag> ogra: So I can download the daily build, run that script on it (where uImage is my own kernel) and it should work?
<ogra> lag, how would the update-initramfs be executed ?
<ogra> (line 67)
<ogra> i assume you run that script on your x86 host ?
<lag> Yeah
<ogra> then it wont work
<lag> Oh?
<ogra> the initramfs needs to be rolled inside the rootfs
<rsavoye> ogra: flash-kernel run on the host or the target ?
<ogra> rsavoye, all run in a booted beagle
<rsavoye> don't see it, let me go look for it
<ogra> lag, you would at least need to chroot into the rootfs and run it there, but it will try to install the modules from the kernel package which is indeed not installed inside your rootfs
<ogra> since you work with raw uImage files
<ogra> lag, if you only rebuild existing kernels and dont fiddle with modules etc i'd just omit the initramfs building completely
<ogra> doing it in a cross way is some effort
<rsavoye> ogra: what package is flash-kernel in ?
<lag> ogra: NP - thanks
<ogra> rsavoye, flash-kernel :)
<rsavoye> I need more coffee....
<rsavoye> You are currently running the Community Kernel edition  ?
<ogra> i'm running the linux-omap or the linux-omap4 metapackages
<rsavoye> should I remove /etc/flash-kernel.conf ?
<ogra> depending on the board/image i run
<ogra> no, /etc/flash-kernel.conf is needed so flash-kernel finds the vfat
<ogra> (which holds bootloader and kernel)
<rsavoye> ah, thanks. Maybe I should try linux-omap too
<ogra> rsavoye, not on the XM ....
<ogra> rsavoye, the XM doesnt find it's SD card currently with the -omap kernel, dont even try it
<rsavoye> ok, thanks for stopping me before it was too late :-)
<rsavoye> ## Executing script at 80200000
<rsavoye> Bad data crc
<rsavoye> oops...
<rsavoye> time to reinstall from scratch I guess
 * ogra calls it a da
<ogra> y
<rsavoye> guess I'll try alpha-3 this time
 * XorA wishes he could just get meeting requests in non garbled forms in linux :-(
<rsavoye> oh well, maverick alp[ha-3 won't boot on an XM
<GrueMaster> mpoirier: Test kernel is booting fine on my 4G Class 2 SD Card.  :D
<rsavoye> dpkg: error processing linux-image-2.6.35-14-omap (--configure):
<rsavoye>  subprocess installed post-installation script returned error exit status 2
<rsavoye> ah, "Cannot find mtd partition 'Kernel'"
<GrueMaster> rsavoye: That's an interesting issue.  Can you try running update-initramfs and possibly flash-kernel separately to see which is hitting this?  I suspect it may be flash-kernel.
<rsavoye> after it reboots, it just hung on me...
<rsavoye> yes, Cannot find mtd partition 'Kernel' comes from flash-kernel
<GrueMaster> I wonder if I am hitting a similar issue with my lucid>maverick upgrade test (which I restarted and is still running).
<GrueMaster> Are you running a maverick image?
<jcrigby> rsavoye:does /etc/flash-kernel.conf exist?
<rsavoye> nope
<jcrigby> update-initramfs sources that file to setup UBOOT_PART
<jcrigby> UBOOT_PART is what flash-kernel needs to know the boot partition device to update the kernel and initrd
<rsavoye> no wonder it won't work :-)
<rsavoye> can I just create the file ?
<jcrigby> yes but update-initramfs may still not call flash-kernel because of another but there
<jcrigby> s/but/bug
<jcrigby> echo UBOOT_PART=/dev/mmcblk0p1 > /etc/flash-kernel.conf
<rsavoye> I'm just trying to get my XM to run long enough to actually compile something
<jcrigby> so you are trying a kernel upgrade?
<jcrigby> update
<jcrigby> ?
<jcrigby> not sure newer kernel will fix anything
<rsavoye> I get Creating backups of uImage and uInitrd... cp: cannot create regular file `/tmp/m
<rsavoye> Failed to create initrd image.
<rsavoye> what's weird is it wants to reinstall the kernel I'm already running
<jcrigby> all flash-kernel does is mount your boot partition and copy kernel and initrd there
<jcrigby> if you are already running the same kernel then this wont help anything
<jcrigby> are you running ubuntu or linaro now?
<jcrigby> I assume linaro since it missing the flash-kernel.conf file
<rsavoye> I think linaro, but the repository seems to point to maverick
<rsavoye> I couldn't get alpha3 to boot, so tried the linaro image, which at least booted
<rsavoye> it's so much more fun to be on the bleeding edge like this :-)
<GrueMaster> Odd.  I could have sworn either ogra or rsalveti had tested Alpha 3 on XM.
<GrueMaster> Ah, found it.  Bug 613855.
<ubot2> Launchpad bug 613855 in jockey (Ubuntu) "Jockey adds outdated debian repo for xerox from openprinting.org (affects: 1) (heat: 39)" [Undecided,New] https://launchpad.net/bugs/613855
<GrueMaster> Err, that's not the right bug.  weird.
<GrueMaster> Bug 613855
<ubot2> Launchpad bug 613855 in linux (Ubuntu) "omap3 beagle XM MMC card always comes up readonly (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/613855
<GrueMaster> Much better (or not, depending on your perspective).
<rsavoye> GrueMaster: I'll gladly try alpha-3 again, but I reinstalled twice and it never booted
<rsavoye> arg, build-dep is braindead
<GrueMaster> I was looking at iso.qa.ubuntu.com.  According to the test results, it fails because the kernel is only seeing the microSD as read-only.
<rcn-ee> rsavoye, that's probally my bad with the /etc/flash-kernel.conf, what am i missing in my images to help users switch between kernels.. My main motivation is to stop 'flash-kernel' when i don't want it to right to flash..
<rsavoye> rcn-ee: I'm trying the linaro image of 2.6.35-14, course it just hung...
<rcn-ee> if it hangs after 'uncompressing' it's basicly bombing on the lack of omap3630 stuff..
<rsavoye> that time it hung running configure
<rsavoye> that is the configure script for Gnash
<rcn-ee> rsavoye, are you going to be around for a bit? got to disable a couple config things to get it built, but i almost have a latest git kernel..
<rsavoye> yep, it's only 1700 here
<rcn-ee> oh, your montain time.. cool central here so basicly the same..  usually everyone's from europe..
<rsavoye> yep, mountain time. I live up at 9000 feet in the Rockies of Colorado
<rsavoye> wow, somebody almost in my time zone ? :-)
<rsavoye> we must be the only 2...
#ubuntu-arm 2010-08-10
<rcn-ee> i belive we are...  i'm not that high up, red river basin in north mn..
 * GrueMaster is in Oregon
<rsavoye> if we had an east coaster we'd cover all the US time zones at least :-)
<GrueMaster> we do.  NCommander.
<rcn-ee> rsavoye, give this one a try.. (it might not even boot, so back up your uImage) but it should detect more of the 'dm37xx' http://rcn-ee.homeip.net:81/testing/2.6.36/2.6.35-git8-dl0.uImage (modules are in the same directory if by some mircrale it works better..)
<rsavoye> how to install ?
<rcn-ee> you have a fat16/32 'uboot' partition on your sd card right? rename your uImage to uImage_bak... Copy this 'uImage' and rename it to 'uImage' if it boots just fine.. untar the modules .tar.gz as sudo right over top the rootfs, it'll create a /lib/modules/$(uname -r?)
<rsavoye> yep. I'll try it after it downloads
 * NCommander waves
<NCommander> rsavoye: hey, how goes it?
<rsavoye> stil trying to get my XM to run stably...
<rsavoye> rcn-ee: you need to upgrade your net connection, an hour to download the uImage ? :-)
<rsavoye> ah, now it's kicking in better....
<rcn-ee> oh, it'll go eventually.... my farm is uploading *.deb images to rcn-ee.net too... it's 30Kb max upload, with my cable access.. sadly noting is better in this country area..
<rsavoye> I know the problem,... I had to start my own rural ISP to get a connection at all...
<rcn-ee> what's funny, digi-key is down the street, so they get 95% of the isp connection.. ;)
<rsavoye> must be nice though if you need hardware :-)
<rsavoye> does this new kernel run at 1Ghz ?
<rcn-ee> i don't think it can yet.. 800mhz still..
<rsavoye> better than 500Mhz... I've been building OpenJDK for 2 days now...
<rcn-ee> some of the new 'base' pm stuff is in it..
<rcn-ee> so rsavoye what's the story?  crash on boot? runs a little bit after boot? or eh it's still going? ;)
<rsavoye> just ate dinner, let me try it
<rsavoye> if I replace uImage with your image it doesn't boot.
<rsavoye> I get funny characters to the serial port
<rcn-ee> sweet, more things broken. ;)
<rsavoye> more to fix that way :-) I'm around if you want me to try another one later
<rsavoye> actually, what was the default baud rate ?
<rsavoye> maybe I need to drop down from 115200
<rcn-ee> oh 115200 been the default, just getting my testsetup up again..
<rsavoye> that was the default for alpha2 and alpha3
<rcn-ee> well it's been the default ever since i booted my first 2.6.21-ish on a beagle. ;)
<rsavoye> I'm using multiple mmc cards now, so I can easily test later, and thrn go back to test builds on2.6.35-14-omap
<rsavoye> sure beats the days of 9600baud only...
<rsavoye> I'm compling Gnash a stress test, C++ code at -O3 is a great way to reproduce memory problems
<rcn-ee> c++ apps are great for that. ;)
<rsavoye> unfortunately...
<rsavoye> funny enough when I build OpenJDL and Icedtea, the java code doesn't cause any problems, only C++ code
<rcn-ee> well it's not a bad thing for stress testing. ;)
<rsavoye> better us breaking it now than after the release. :-)
<rsavoye> compiling away on 2.6.35-14-omap, before it never ran for more than 15minutes, so I'll let you know...
<rcn-ee_lpt> hey ogra, from the irc log it looks my 'unique' /etc/flash-kernel.conf is messing some people up, is there a minimal amount of stuff i should put in there, before my 'to use ubuntus kernel remove the next command' 'exit 0'?
<GrueMaster> He's in Germany.  3am.  If he answers, I would be very surprised.
<GrueMaster> What does your flash-kernel.conf look like?
<rcn-ee_lpt> yeap, i was hoping he was doing some midnight coding.. ;)
<rsavoye> I think we're the only ones awake
<rcn-ee_lpt> the one /etc/flash-kernel.conf i'm adding to my images was for the lucid days, but it sounds liek maverick needs more stuff:  http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/image-builder/annotate/head:/tools/fixup.sh
<rcn-ee_lpt> the DONT_FLASH part was a patch i was working on but dropped..
<GrueMaster> Lucid wrote the kernel to nand, Maverick uses a 70M fat32 partition.  It needs to have UBOOT_PART=<vfat partid> in it.
<GrueMaster> especially for XM and systems w/o nand.
<rcn-ee_lpt> eh, that's what i'm missing, thanks GrueMaster i'll add it to the next upload, and tweak the message to make it easier for users trying to switch between. ;)
<rcn-ee_lpt> actually i originally wrote it for my xm with lucid, after which i found out the netinstall would just crash with lack of nand on my xm. ;)
<GrueMaster> Something like this?  http://paste.ubuntu.com/475699/
<rcn-ee_lpt> i'd personaly remove all nand stuff.. ;) to many rma's and confused customers.. ;)
<GrueMaster> Makes sense.
<rcn-ee_lpt> almost number one reason the xm doesn't have nand..
<rcn-ee_lpt> on the other hand it's a nice clean install for a single distrubution.. ;)
<GrueMaster> Interesting how we went from having to show people how to program their VCR to having to show people how to program their embedded development system.
<rcn-ee_lpt> you didn't use electrical tape? ;)
<GrueMaster> For my VCR?  Had a roll on an office tape dispenser next to it.
<rcn-ee_lpt> but yeah, over the last year, my wiki has gone from.. follow these examples exactly too run this script...
<rsavoye> less tech support that way
<GrueMaster> Now if TI (or one of their oems) were to make something like this...http://en.qi-hardware.com/wiki/Ben_NanoNote
<rcn-ee_lpt> that would be neat to have.. i'm been looking at this.. omap3530 powered http://www.slashgear.com/nationite-midnite-android-2-2-mid-an-affordable-cortex-a8-tablet-0696771/
<rsavoye> so far so good, one directory compiled without segfaults
<rcn-ee_lpt> is that with 2.6.35-14-omap?
<rsavoye> yeah
<rsavoye> from the linaro image
<rsavoye> how can I see what clock speed it's running at out of curiousity ?
<rcn-ee_lpt> cat /proc/cpuinfo...
<rsavoye> ah, 500Mhz. oh well... :-)
<rsavoye> still, sharing a beagle board in NZ is kindof slow...
<rcn-ee_lpt> well.. by default u-boot set's it up for 500, passes mpurate to the kernel, (which i don't think ubuntu
<rcn-ee_lpt> 's boot.scr uses yet...
<rsavoye> if it's stable, I'll be glad to have that than a higher clock rate
<rcn-ee_lpt> yeap, right now stable on an xm is better then anytyhing..
<prpplague> rcn-ee_lpt: could be on a beagle mounted on a mars rover
<prpplague> rcn-ee_lpt: i'm thinking the ping times would be pretty large
<rcn-ee_lpt> that would be cool prpplague you'd have to script everything no point in waiting for commands..
<rsavoye> the spec for the Delay Tolerant Network is pretty cool
<rsavoye> it's the exact opposite of real time...
<GrueMaster> Just be thankful this hasn't become a standard yet.  http://www.faqs.org/rfcs/rfc2549.html
<GrueMaster> Although if MS ever hears about it...
<rcn-ee_lpt> well, they'd just implement it after bsd. .;)
<prpplague> GrueMaster: i thought they already implemented it in wince, that's why it runs so slow
<GrueMaster> Heh.
<rcn-ee_lpt> rsavoye, it's funny.. that uImage booted for me.. (well dss2 is broken so no screen)
<rsavoye> should I do anything after copying the uImage ?
<rcn-ee_lpt> nope, just the uImage... lets see if it survies my aptitude test..
<rcn-ee_lpt> nope, crash.. can't wait for a production unit. ;)
<rsavoye> aaarrrggg, same ol segfault. oh well...
<rcn-ee_lpt> i get this... dss2 is broke.. http://pastebin.com/1UpFddvN
<rsavoye> I get http://paste.ubuntu.com/475715/
<rsavoye> it segfaults still, but differently than when I ran your other kernel a few days ago
<rcn-ee_lpt> yeap, we are still missing the usart3.. (basicly the omap3630 core added another usart ove rthe omap35xx) it hasn't been implemented yet..
<rsavoye> guess this will make me eager to test new kernels, hoping one works :-)
<lag> rcn-ee: Are you here/
<lag> cooloney: Morning
<cooloney> lag: morning, man
<cooloney> you are very early
<lag> I'm always here 0700-30
<lag> cooloney: bug 612895
<ubot2> Launchpad bug 612895 in linux-ti-omap4 (Ubuntu) "Unable to handle kernel NULL pointer dereference at virtual address 00000000 (affects: 1) (heat: 1674)" [Undecided,Confirmed] https://launchpad.net/bugs/612895
<lag> And the kernel you asked me to test
<lag> Where did you get the _fix_?
<cooloney> lag: i saw you are trying 902 kernel. and we just upgraded to latest TI release
<cooloney> lag: maybe you can try that
<cooloney> lag: the latest TI release fixed one swap oops
<cooloney> ndec: morning
<ndec> cooloney: morning.
<lag> ndec: Morning :)
<lag> cooloney: When did you update?
<ndec> lag: morning!
<cooloney> lag: tim pull it last week. it is 2.6.34 based release
<cooloney> not 2.6.35
<hrw> morning
<zumbi> hrw: hi
<zumbi> hrw: where do you keep your compilers packaging
<hrw> zumbi: 2 places
<hrw> 1. http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/
<hrw> 2. https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler
<hrw> 1st has cross compiler packages
<hrw> 2nd has my work on binutils/eglibc/gcc and related packages
<zumbi> hrw: should we try to sync on getting this into Debian together?
<zumbi> (or you might not care on Debian?)
<hrw> zumbi: all my work is first in Debian ;d
<zumbi> while most of the work is fine, I have some suggestions on the packaging
<hrw> zumbi: zless /usr/share/doc/gcc-4.4/changelog.Debian.gz please
<hrw> zumbi: I am listening
<zumbi> hrw: yes, i saw that changelog, but i do not see it on linux, nor eglibc
<hrw> linux in Debian is other recipe then in Ubuntu...
<hrw> zumbi: I need: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=b4f64f3350b628323e39f69b416523f60c7f11f2 http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=b4c776c2bc2c183fe13d3ed5f23e00fd9cb62a1d in kernel source package
<zumbi> hrw: while one package for cross compiler (armel-cross-toolchain) could be fine. I would suggest to do some package split for building reuse
<zumbi> hrw: I have some dependency graph which might clarify package dependencies a little
<hrw> ok
<zumbi> hrw: I need some time to build an image of the dependency graph (source at: http://emdebian.org/git/?p=talks/emdebian.git;a=blob;f=pkgdeps.dot;h=9380b2fb14c6ffb6ecb66c05bc71cb375098531f;hb=HEAD )
<zumbi> hrw: I'll ping you back once i get a better looking file
<hrw> ok
<hrw> what you use to visualize it?
<lool> dotty
<zumbi> dot -Tdot pkgdeps.dot | gvpr -c '' | dot -Tpdf -o pkgdeps.pdf
<zumbi> brb
<hrw> thx
<lool> hrw: So you're essentially building a package which takes as input *-source, and outputs all the cross-toolchain .debs; I think zumbi is looking for some modularity, such as building binutils separately, or not rebuilding all stages; I don't think all the modularity is easy, so let's shoot at completing a cross toolchain first, and then we will make it more modular
<lool> My understanding of zumbi's main concern is the time it would take to build the whole bootstraped toolchain
<lool> I personally think this is ok, but I understand why he would like to skip some stages / packages in Debian
<hrw> 56 minutes on my core2quad
<lool> sweet
<hrw> zumbi: your graph has a bug. 1st stage of gcc do not need eglibc
<hrw> zumbi: and do not need linux headers - thats what eglibc wants
<zumbi> back
<zumbi> hrw: the most important think i wanted to show you from the graph is capability to rebuild non default compilers
<zumbi> hrw: so if default is 4.4, you could reuse all libs to rebuild 4.3, 4.5, ..
<hrw> zumbi: take my armel-cross-toolchain source package, change component inside, build
<hrw> version of gcc inside is set by VER_GCC variable
<hrw> 4.4 and 4.5 should work
<zumbi> hrw: ok - i'll do
<hrw> 4.3 is not present in ubuntu so I did not changed it
<hrw> if you want to use <4.4 then you will need to merge changes from 4.4
<hrw> and there are still lot of changes which I need to merge
<zumbi> hrw: but you no need to rebuild everything for both compilers (that was my suggestion) :)
<hrw> phone...
<lool> zumbi: Yes, in general, the structure of cross-compiler packages is not perfectly defined
<lool> zumbi: for instance, which package should provide $triplet-gcc?
<lool> zumbi: My take on this is that there are two types of users: a) people who want to quickly build a standalone cross-toolchain
<lool> and b) people who want to build cross compiler packages which match as much as possible the native toolchain
<lool> for the later case, I think we need to output -gcc-4.5, -gcc-4.4 and -gcc files, and that should be the default; for the former I think we should add a flag to the gcc cross-build to allow building a standalone package
<zumbi> lool: and c) people wanting to just intall the binaries :)
<lool> zumbi: I'm not sure what you mean
<lool> I think the in-archive packages should be of type b), but they will be of type a) in the beginning
<zumbi> lool: right
<zumbi> lool: sounds fine
<hrw> I think that we try to make a) == b)
<hrw> at least thats my goal with ubuntu packages
<lool> hrw: Hmm, I'm not sure it's possible
<lool> hrw: Consider that gcc comes from gcc-defaults right now
<lool> hrw: And that people might want to build a standalone cross-toolchain which ships $triplet-gcc, even if it's not the gcc-4.x they build from is not the default
<hrw> my wife is refuelling our car for first time so I am remote helpdesk
<hrw> lool: current ubuntu cross gcc packages (4.4 4.5) ships $triplet-gcc-VER + u-a stuff to make it $triplet-gcc (gcc/cpp/gcov/g++ etc)
<lool> hrw: yeah, alternatives suck though    :-/   but it's good to have that in place at least
<hrw> speaking of cross-gcc-defaults package... I looked at gcc-defaults one and I think that will make new one based on it instead of adding cross support to this one.
<hrw> armel-cross-toolchain 1.7 builds now. will fail anyway
<hrw> 1.8 on a way
<rcn-ee> lag pong
<lag> Hi Robert
<lag> Your patch for ro
<rcn-ee> how's it going lee..
<lag> Are you going to push it upstream?
<lag> Good thanks :)
<rcn-ee> for the xm, when the hardware is released, i'll send it to linux-omap, it'll probally get tweaked..
<lag> rcn-ee: Why don't you throw it up there now?
<rcn-ee> i don't really have a good excuse. ;)
<lag> The boards don't work without it
<lag> Is that good enough? ;)
<rcn-ee> i'll run it thru the patch checker script, and sent it to linux-omap, one more thing enabled for the xm..
<ogra> \o/
 * ogra sighs about oem-config
<ogra> i also just stopwatched the resizing ... 2:30 for two boots and the whole resizing process on a 4G card
<ogra> (each boot takes 35sec for u-boot until the kernel comes up)
<ogra> amitk, do you still think thats to slow ? :)
<hrw> 2h30m?
<ogra> 2min 30sec :)
<ogra> of which 1min 1sec are simply u-boot stuff
<ogra> err
<ogra> 10sec
<hrw> ogra: and how much from first start to final desktop?
<ogra> hrw, no idea, thats from pushing in the power plug to oem-config
<rcn-ee> 35 seconds for u-boot? you could cut the u-boot wait variable.. ;)
<hrw> oem-config etc took ages last time
<ogra> answering the oem-config questions will likely take another 2-3min (depending how fast you type and click) plus package removal time which i couldnt stopwatch yet
<amitk> ogra: no, it is loooking _much_ better. Congratulations :)
<ogra> note that i'm talking about omap4 here
<ogra> i dont test on the C4 anymore and XM is currently broken kernel wise
<hrw> on Cx you have to multiply by 10
<rcn-ee> still pretty quick, is your u-boot for the omap4 like the omap3, where it has a 10 second wait at boot?
<amitk> ogra: I know you cheated :-p But it is still a lot better than the 1.5hr installs
<ogra> hrw, well, if we get the XM working i wont recommend the images for Cx installations
<hrw> ogra: so far I am stick with C3s anyway
<ogra> its simply not up to par with the minimal requirements
<hrw> btw - how often does ubuntu devs reboot their 'desktops'?
<rcn-ee> sweet, looks like a real patch for 588243 just it linux-omap..
<ogra> after update-manager forced me to
<hrw> ogra: I am ~5 kernels behind current
<amitk> bad hrw
<ogra> yeah
<ogra> you should listen to your update-manager :)
<hrw> ogra: aptitude do not said anything ;D
<ogra> shudder
<ogra> dont use aptitude
<amitk> hrw: aptitude is not recommended by our update guys
<hrw> so what :D
<amitk> it resolves dependencies in a different (unsupported) way
<hrw> I cant stand other apt utils then aptitude and apt-get
<ogra> hrw, do-release-upgrade is what you want if you are a cmdline guy
<hrw> if it require me to use mouse then it is not good
<hrw> 13:56 hrw@home:debian$ sudo do-release-upgrade
<hrw> [sudo] password for hrw:
<hrw> Checking for a new ubuntu release
<hrw> No new release found
<ogra> its the equivalent to update-manager
<ogra> what are you running ? lucid or maverick ?
<hrw> maverick since uds
<ogra> ah, that might be different
 * ogra doesnt run maverick on his main machine
<amitk> what's wrong with 'sudo apt-get update; sudo apt-get dist-upgrade -V'
<ogra> nothing
<hrw> amitk: aptitude logs what I isntalled etc
<ogra> hrw, apt too
<hrw> ogra: it did not when I started using aptitude
<amitk> hrw: /var/log/apt/
<hrw> aptitude also shows what new, what local/obsolete etc
<ogra> apt-get autoremove :P
<hrw> I used console-apt and few other ncurses/slang frontends in past
<ogra> ah, you need a gui ?
<ogra> well
<hrw> ogra: that does not tell that libdvdcss2 is from outside of ubuntu
<hrw> or that binutils-arm-linux-gnueabi is also not ubuntu package
<ogra> why didnt you use the one inside of ubuntu ?
<ogra> (for DVD playback, use libdvdread4 and run /usr/share/doc/libdvdread4/install-css.sh )
<hrw> do not remember now
<hrw> ogra: that script does same as I did - fetch pacakge and install
<ogra> yeah
<ogra> likely
<hrw> but I play one dvd per year so...
 * amitk doesn't even have a laptop with dvd drive any more
<hrw> did I said laptop?
<ogra> mine annoyingly has one
<hrw> I never owned laptop with drive
<ogra> (with an eject button you always hit if you lift it)
<hrw> ogra: remove it from case?
<ogra> then i have an open hole in my lappie
<ogra> the drive is customized to the case
<ogra> and i have no placeholder or something to put into the empty slot
<hrw> so nothing other can fit?
<ogra> i guess when the laptop was recent you could buy dummies to put into the slotr
<ogra> but thats 2.5 years ago and the model isnt produced anymore
<lag> rcn-ee: Sounds good (I saw that your tabs are out, besides that it looked okay)
<rcn-ee> yeah, noticed that when i added the patch to the lp bug.. (crap wrong tabs..) btw, i think this fixes lp bug 588243 http://www.spinics.net/lists/linux-omap/msg34582.html going to test it this morning..
<ubot2> Launchpad bug 588243 in linux-ti-omap (Ubuntu) (and 1 other project) "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/588243
<lag> rcn-ee: That's a lot of extra code
<lag> :)
<lag> I'm sure cooloney will be glad to hear of it
<lag> rcn-ee: I'm commented on the bug with your information
<lool> ogra: Around?
<lool> ogra: Do you remember that discussion about changing the image generatin to output fat32 specifically?
<ogra> lool, yes, i changed it for you back then, does it work now ?
<lool> No
<lool> That's why I'm around
<ogra> iirc we still have a bug open thats pending confirmation
<lool> One thing I noticed, and I had mentioned on IRC, is that the number of heads is non-default when I regenerate it here
<ogra> "regenerate" ?
<lool> ogra: If you sudo losetup -fv maverick-preinstalled-netbook-armel+omap.img, then sudo kpartx -av /dev/loop0, then compare: sudo fdisk -l /dev/loop0
<lool> and sudo file -s /dev/mapper/loop0p1
<lool> you'll see that they don't have the same number of heads
<lool> yep, confirmed, that fixed it for me
<ogra> the CHS geometry is indeed adjusted to the image size, i havent seen any issues with dd'ed images
<lool> ogra: So if you check the number of heads in the FS, it says 64; if I regenerate the fs, copying back the same files in, it generates a FS with 255 heads here, and it boots in QEMU
<lool> (now it doesn't work because I get no keyboard and no /dev/mmcblk0p2, but still it will boot into the initramfs!)
<ogra> {
<ogra>     echo ,9,0x0C,*
<ogra>     echo ,,,-
<ogra> } | sfdisk -D -H 255 -S 63 -C $CYLINDERS $IMAGE >/dev/null 2>&1
<ogra> thats the code from the debian-cd script (which originally comes from angstrom)
<lool> this isn't the problem
<ogra> but that defines the sectors
<lool> I'm speaking of the heads in the *filesystem*
<ogra> err, heads indeed
<ogra> mkdosfs -F 32 -C $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1
<ogra> thats the filesystem creation, with -F32 added as you requested
<ogra> could it be that our mkdosfs on antimony is to outdated ?
<lool> Maybe, but looking at the code, I rather think that it's because I'm running it on a different device that I get different results
<lool> Current images: /dev/mapper/loop0p1: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID " mkdosfs", Media descriptor 0xf8, heads 64, sectors 144522 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1112, serial number 0x4c5f659b, label: "           "
<ogra> that might be, i get proper partition tables and filesystems if i use it from SD card
<lool> after mkdosfs on a loop device:
<lool> /dev/mapper/loop0p1: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID " mkdosfs", Media descriptor 0xf8, heads 255, sectors 144522 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1112, serial number 0xcafca2f1, label: "           "
<ogra> weird
<lool> >-------printf ("unable to get drive geometry, using default 255/63\n"); bs.secs_track = CT_LE_W(63); bs.heads = CT_LE_W(255);
<lool> interestingly, it tries to default to 64 heads on loop devices, but fails to detect my device as a loop device
<ogra> kernel issue ?
<lool> ogra: Well it's just that it checks for loop major device (7), but I'm using a mapper device (major 252)
<ogra> ah
<ogra> but could that in any way affect your qemu boots ?
<lool> 252 actually means "local/experimental use"
<ogra> i doubt it
<lool> qemu apparently reads the number of heads from the FS
<lool> and refuses to boot with heads == 64
<ogra> hmm
<lool> I need to say that the partition table actually says 255, so QEMU has a point in not booting   :-)
<ogra> but the 255 is needed for real HW :)
<lool> the 255 is fine
<lool> the bogus part is the 64 heads in the FS
<ogra> 255/63 is a requirement, else x-loader wont work
<lool> Err which 63 is that?
<ogra> sectors
<lool> I'm only speaking of heads here
<ogra> the DOS standards
<lool> sectors don't matter really
<lool> (here)
<ogra> not here but for the actual images, the partitioning needs to be that way, i dont know how i would change the amount of heads the filesystem uses though, seems mkdosfs has no option for that
<lool> so it's a set of mkdosfs bugs, but not fun to fix
<lool> ogra: it's because mkdosfs has a different code path for files and for devices
<lool> for files, it checks the size and defaults to 32 sectors and 64 heads
<lool> for unknown devices, it assumes hard disk and checks the geometry, but fails and so uses 63 sectors per track and 255 heads
<ogra> meh
<ogra> lool, i'm planning to provide a script that loop mounts and reformats the vfat for bootloader changes on existing images, we could have some workaround in there that makes it work for you too
<ogra> (we want to provide the same image for blaze and panda but that requires different x-loader and u-boot)
<lool> ogra: i'd rather fix mkdosfs
<ogra> lool, in hardy ?
<ogra> dont forget antimony is hardy
<lool> ogra: Well we can certainly prepare a special fixed package to install there
<ogra> indeed
<lag> ogra: If I want to test my bespoke kernels with the daily image - what's the easiest way?
<lool> ogra: Hmm it's more complex than I thought
<lool> LP #615873
<ubot2> Launchpad bug 615873 in dosfstools (Ubuntu) "Doesn't allow forcing file systems to 255 heads (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/615873
<hrw> someone remember how to tell "dch" to not use "ubuntu1" but bump version?
<lool> hrw: Bump to what?
<lool> hrw: You can -i to force a version increment, or -a to force not touching the version; you can -v to set the version
<GrueMaster> lag: what platform do you want to test on?
<lag> Arm
<GrueMaster> Duh.
<GrueMaster> Little more specific.
<lag> OMAP3+4
<GrueMaster> If you want to test on Beagle & Panda, probably easiest to use the Alpha 3 image and install kernel after the image expands and oem-config runs.
<GrueMaster> If you want to test on XM, boot an image on beagle first, then install new kernel.
<GrueMaster> Not sure if you can just put the uImage on the image w/o updating uInitrd.
<lag> Hmm
<lag> You can't
<lag> depmod not found
<lag> So, let them come up and install kernel.deb after?
<GrueMaster> That would be easiest.
<rsavoye> alpha3 has problems still on my XM
<GrueMaster> yes, I know.
<GrueMaster> The other possible way is to generate an image with rootstock, but I don't know how well that works.
<hrw> lool: yes, but -i bumps from 1.10 to 1.10ubuntu1 when I want 1.11
<rsalveti> yep, with rootstock you can give the kernel image to be used while creating the rootfs
<lag> rsalveti: But I want to test it with the daily build
<lag> rsalveti: i.e. the daily build's rootfs
<rsalveti> GrueMaster: lag: another way is to copy qemu-arm-static to <sd-card>/usr/bin and run chroot
<rsalveti> after that you're able to install normally
<lool> hrw: --distributor Debian?
<rsalveti> lag: well, the advantage of using rootstock is that you can test another kernel easily, without having to wait the daily rootfs to be created
<hrw> lool: ok, thx
<lag> rsalveti: I have kernels that I know work with rootfs, but they don't when they're used with the daily build
<lag> rsalveti: I need to test them with the daily build's rootfs
<rsalveti> lag: so, installing the new kernel deb with chroot is how I'd recommend you to do it
<rsalveti> if you don't have access to the machine running your rootfs
<rsalveti> but then you need to create and copy uI* files
<lag> Does the daily build's rootfs have update-initramfs?
<lag> And mkimage?
<rsalveti> GrueMaster can easily check
<GrueMaster> yes, they do.  Sorry, had to step out for a bit.
<ogra> lag, create a package, dpkg -i it
<ogra> lool, well, my offer still stands, i can add a special mode to the script
<lag> But that's saying I have a running system
<lag> ogra: XM is borked
<ogra> lag, yeah
<lag> How how can I dpkg -i on the XM?
<ogra> lag, another way is to dpkg -i your package in a chroot and just use mkimage on the files
<ogra> and then replace them on the SD
<lag> Yeah, that's whay rsalveti said
<lool> ogra: It looks like we're creating a broken vfat
<lool> I'm worried about mtools_skip_check=1
<ogra> thats what i do for jasper development
<ogra> lool, iirc we a) use that elsewhere too in debian-cd, b) as long as the bootloader likes it i'm fine, we repartition and recreate the vfat on first boot anyway
<ogra> lool, seems the only thing that doesnt cope with our images is qemu here
<lag> ogra: Can I just update-initramfs <kernel-image> in a chroot and use the uInitrd and uImage files?
<ogra> lag, you need the mkimage calls too
<ogra> but yes
<lag> What do I need to do with the rootfs?
<ogra> nothing
<lag> Just copy the modules into /lib/modules?
<rsalveti> lag: yep
<ogra> just dpkg -i your package or create the modules dior manually
<rsalveti> lag: the packages just installs the modules
<rsalveti> then depending on your changes you need to generate the initrd.img again
<rsalveti> then create the uI* files and rock on
<lag> Why do I need to make them twice?
<lag> Compile kernel
<lag> Make uImage
<lag> Make uInitrd.img
<lag> Make uInitrd
<lag> Copy to rootfs
<lag> Copy modules to /lib/modules
<lag> Done
<ogra> lag, just roll your kernel inside that chroot :)
<lag> ?
<lag> I do
<ogra> mak install will put the modules in place
<ogra> *make
<lag> I don't do make install
<lag> I have to do it manually
<ogra> well, make modules_install
<lag> Nope
<lag> I build on a different <remote> machine
<ogra> well, have an armel chroot there you can build in
<lag> I do
<ogra> wrap a script around it that spits our uImage/uInitrd
<ogra> *out
 * cpearson wonders if there are any Canonical guys at LinuxCon? Need someone to drink beer with tonight :)
<ogra> cpearson, mdz i think and kees
<cpearson> ogra: ping me with real names if you could
<ogra> cpearson, what happened to the photo from prague btw ?
<ogra> cpearson, matt zimmerman and kees cook
<cpearson> http://ufgeek.wordpress.com/
<ogra> (no secret :) )
<ogra> awesome !
 * cpearson does not have magic decoder ring for IRC nick to names :)
<cpearson> ogra: thanks
<rsalveti> lag: don't you need to generate the initrd.img first before creating the uIinitrd?
<rsalveti> you said make uInitrd.img
<kblin> cpearson: you clearly need to eat more geek flakes
<cpearson> the marketing gig is making me soft
<lag> rsalveti: Don't you use update-initramfs <kernel-image> to make uInitrd.img?
<rsalveti> lag: yep, but I create the *initrd.img* file, not uInitrd.img
<lag> http://ufgeek.wordpress.com/ - WTF!
<lag> I have a stalker
<cpearson> lag: damnit now you found me, I have to move to the other set of bushes outside your house
<lag> ogra: cpearson: http://people.canonical.com/~ljones/lastsupper/
<lag> rsalveti: Picky!
<lag> rsalveti: But you get the idea
<rsalveti> lag: yep, but the *u* on it means that you don't need to run mkimage :P
<cpearson> ogra was confused... we had been drinking
<ogra> heh
<cpearson> and there was schnitzel
 * ogra had duck though
<cpearson> and an accordion
<ogra> possibly a mad duck :)
<cpearson> I'm sure we was briefly pissed... then they took his head off
<lag> What was the lexicographic revelation? My spelling mistak?
<lag> ;)
<lag> cpearson: ?
<cpearson> lag: the meaning of the middle F
 * cpearson looks at the #linux-omap channel... man there are some strange people in there :)
<GrueMaster> And we're not strange?  I'm offended.  :P
<rsalveti> XorA|gone: regarding the texture from pixmap stuff, check https://wiki.linaro.org/Platform/UserPlatforms/2010-08-10 and http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg11616.html to see how linaro and mesa guys are working with it
<rsalveti> if you didn't read this already :-)
<rsalveti> XorA|gone: alf__ and asac are working to understand if it's really needed to get this proprietary extension implemented on the driver side
<rsalveti> or if it should just follow the common extensions like mesa guys are doing
<XorA|gone> rsalveti: email me rather than talk here, Ill lose these logs before I get to read them
<rsalveti> XorA|gone: your email?
<XorA|gone> gg@slimlogic.co.uk
<rsalveti> k
#ubuntu-arm 2010-08-11
<ework> hello room
<ework> has anyone had any success getting ubuntu 10.04 or 10.10 working on a Keil Versatile Express development board?
<GrueMaster> What processor does that use?
<ework> I think the problem I'm having is the kernel has an incompatible config
<ework> A9x4
<GrueMaster> ?
<ework> 4 core A9
<GrueMaster> oh.
<mattman> ework: i have been able to boot a kernel on that system
<ework> I have been able to boot generic debian lenny using debootstrap and the stock kernel from ARM (kernel-2.6.33-arm1)
<mattman> ework: do you want me to send you the .config i've been using?
<ework> when booting a rootfs built using rootstock it just hangs after a number of errors about plymouth
<ework> but its still detecting my usb keyboard being plugged in and unplugged
<ework> I had to add support for DEVTMPFS in my kernel to get past some of the initial errors
<ework> mattman, what kernel were you using?  was is something derived from the ubuntu kernel?
<mattman> ework: 2.6.35-rc5.
<ework> mattman, that would be really great
<ework> thats a maverik kernel correct?
<mattman> ework: just a sec working on getting it into pastebin
<ework> mattman, where is the best place to get the patched ubuntu kernel source so that I can apply this patch against
<ework> mattman, did you just do a standard "make uImage" after patching it?
<mattman> ework: i haven't patched the kernel.  i'm pretty sure this is just a snapshot of the arm-next kernel tree.
<ework> mattman, whats the best way to cross compile the kernel.  Sorry I'm just getting started with this stuff.  I've built the kernel a number of times using the standard ubuntu way to a .deb file, but not cross-compiled a kernel from a ubuntu source package.
<mattman> ework: can you see the arm-next kernel at http://git.linaro.org/gitweb?
<ework> mattman, I also have no problem compiling a kernel from vanilla source, which is how I get the 2.6.33-arm1 kernel I have now
<ework> ok I think I can figure it out from that git source
<ework> mattman, did you make this config yourself or is it based on some source
<mattman> ework: ok let me pastebin a link to the .config I'm using
<ework> mattman, sorry for all the questions I'll slow down
<mattman> ework: yes
<mattman> ework: here's the .config i'm using: http://pastebin.com/D8fUQ1bK
<mattman> ework: i created this by using an older .config and just manually enabling the same devices.
<ework> mattman, so you were able to boot some form of ubuntu on the versatile express correct?
<ework> using this kernel and rootstock?
<mattman> ework: yes right now I booted a minimal rootfs then apt-get the rest.
<ework> mattman, sounds good that was my plan as well
<mattman> let me send you a link to some wiki instructions i put togther.
<mattman> ework: https://wiki.linaro.org/Boards/Vexpress - actually after looking at the instructions again, they are good for when you already have built images. i need to spend more time explaining how i built the images
<ework> mattman, thank you for all the help you have no idea how much time I've spent spinning my wheels trying to debug why it doesn't boot
<ework> mattman, I can add some information tho this wiki as I go through the process if that helps
<ework> looks like I just need a launch pad account which is not a problem
<mattman> ework: good to know. i wondered if the instructions were visible.
<ework> mattman, btw one other boot option is usb which is what I've been using without problems
<mattman> ework: that's good to know also. i would like to add any information you'd like to share to the document.
<ework> mattman, I should be able to add information myself if I have a launchpad.net account?
<mattman> ework: true
<mattman> ework: that's even a better ides ;-)
<ework> mattman, oh you have usb hard drive already at the bottom
<ework> mattman, this looks similar to whats on the quickstart card.  I think you might even want a separate page for building the kernel and rootfs
<mattman> ework: right, seems obvious now that i look at it again.
<ework> mattman, well its kind of obvious now but it took me a while to understand it to the level documented there
<ework> mattman, I didn't even know you could boot the kernel off SD or CF I was always updating the flash each time
<mattman> ework: that's pretty nice if you have an SD card reader on your laptop.
<ework> yah I have the board next to my laptop and can just unplug it and take the card out and put it into a MicroSD to SD adapter
<ework> copy it over and reboot and it updates the flash
<mattman> ework: just one more item that might help. i don't remember exactly where my minimal rootfs came from, but i think http://releases.linaro.org/platform/linaro-m/headless/alpha-3/linaro-m-headless-tar-20100803-0.tar.gz may work.
<ework> mattman, this wiki page is very useful but I agree it needs to complimented with instructions for building rootfs and kernel
<ework> mattman, the minimal rootfs is pretty easy to get using rootstock
<mattman> ework: thanks for the feedback on the wiki page.
<ework> mattman, maybe it had some incompatibilities which is why I ran into problems
<NCommander> ericm|ubuntu: ping?
<dyfet> this is a lovely day
<lag> Morning ogra
<dyfet> i am not sure he is up yet
<lag> lazy blighter
<lag> dyfet: David, maybe you could help?
<dyfet> maybe
<lag> I am trying to run update-initramfs from a chroot
<dyfet> hmm...
<lag> What do I need to make it work?
<dyfet> well, for other odd things in chroot, I would suggest bind mounting /dev, /proc, and /sys. but I am not sure if that is helpful for this.
<lag> How do I know of they are bind mounted or not/
<lag> ?
<dyfet> well, from outside the chroot, you can do "mount" to see what is mounted
<cooloney> lag: are you reviewing the L24.9 kernel release from TI?
<lag> cooloney: I'm happy to
<lag> cooloney: But I haven't had an email
<lag> dyfet: I'm not sure this will help me
<lag> cooloney: How do you test your bespoke kernels with the daily build?
<dyfet> I have used that for things like grub from chroot, but I am not sure if it is helpful for running update-initramfs from chroot either...
<lag> dyfet: I think I just need to know how to run it
<lag> Where does it get it's modules from?
<cooloney> lag: oh, i assume ndec told you the git tree for that L24.9 kernel in irc
<cooloney> lag: hmmm, what's bespoke kernel?
<lag> cooloney: bespoke == your own
<lag> cooloney: Not yet
<cooloney> lag: now, i just build kernel and flash it into my SD card with a maverick rootfs built from rootstock
<cooloney> lag: how about you?
<lag> cooloney: I don't
<lag> cooloney: I'm trying to, but it means I have to re-create the initramfs from within the chroot
<lag> cooloney: This, I am having difficulty with
<hrw> morning
<cooloney> lag: yeah, i also installed a daily image on another SD card.
<cooloney> lag: so if I wanna test it, i can use that SD card.
<dyfet> cooloney: I do much the same...
<lag> But I'd like to test them in unison
<lag> New kernel w daily build rootfs
<lag> cooloney: It's not a problem for you, as the daily build boots
<lag> But it doesn't on XM
<cooloney> lag: oh, too bad, XM looks scary to me
<lag> I need to re-create the uImage and uInitrd from the get-go
<lag> cooloney: Not scary, just a pain
<cooloney> lag: how about just boot uImage, use 'noinitrd root=/dev/mmcblk0p2' in kernel cmdline to skip uInitrd
<cooloney> i mean for testing kernel booting and some bugs which can be found in console.
<lag> cooloney: No - some of the issues are; boots fine with rootstock, doesn't boot with daily build
<cooloney> lag: oh yeah, i c
<lag> cooloney: Some issues only surface when using the daily build
<lag> cooloney: I need to create a uInitrd for my 'bespoke' kernel
<dyfet> I think I will try getting some sleep
<lag> dyfet: :)
<lag> dyfet: Night David
<cooloney> dyfet: good night, have a nice dream
<cooloney> don't dream of XM
<lag> cooloney: The term you're looking for is "sweet dreams"
<lag> Okay I'll have to wait for ogra or rsalveti, as they seem to know a little about initramfs'
<cooloney> lag: yeah, actually the uInitrd i am using still comes from rsalveti
<cooloney> lag: i just updated a bug tracker you pointed me a patch yesterday
<lag> cooloney: I can't take credit for that, you have to thank rcn-ee
<lag> cooloney: I saw your ACK on linux-omap
<cooloney> lag: yeah, rcn-ee is robert?
<cooloney> rcn-ee: thanks a lot
<cooloney> lag: yeah, just tested on my board
<lag> cooloney: Yes, that's Robert
<cooloney> i think the patch author stanley.miao might be in China who works for windriver
<lag> stanley.miao@windriver.com
<lag> I'd say you're right :)
<cooloney> lag: i found there are hundreds patches from TI's L24.9 release
<cooloney> lag: mission impossible for us to review all of them
<lag> cooloney: With the last lot, did you go through them all individually?
<cooloney> lag: no, just reviewed several
<lag> cooloney: What about the 200+ ones you received?
<cooloney> lag: i plan to add our ubuntu packaging stuff firstly
<cooloney> lag: OMG, you don't know that?
<lag> ?
<cooloney> lag: i pushed them out and tim merged them as 903.7 release in ti-omap4 tree
<cooloney> L24.9 is new release which is based on 2.6.35
<lag> Yes, but you must have reviewed them first
<cooloney> lag: oh, i fixed lots of codings style issue
<lag> Yes, but did you thumb through and review them all individually?
<cooloney> reviewed most of them not all of them
<lag> And how many hundred are there in this release?
<cooloney> yeah, but just quick review.
<lag> Do you have the link?
<cooloney> i guess 900 or more
<lag> JC
 * lag falls on the floor!
<cooloney> and still increasing
<cooloney> 1 sec, man
<lag> Well you'll have fun this those
 * lag leaves
 * cooloney grabs lag back, 
<cooloney> http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.9
<lag> Noooooooooooooooooooooooooooo
<cooloney> lag: come on. hehe,
 * cooloney brb 
<lag> How do you know there are 900?
<lag> Are there stats?
<cooloney> lag: i just wanna scare you
<lag> nec: Good morning
<ogra> lag, whats your prob ?
<lag> ogra: What's your problem?
<lag> ogra: ;)
<ogra> oh, dont get me started :)
<ogra> i mean your initramfs issue
<lag> ogra: I want to create an uInitrd that will work with the daily build
<ogra> what did you do so far
<lag> Create kernel.deb
<lag> Create uImage
<lag> Extract kernel.deb (before create uImage)
<lag> ?
<ogra> install qemu-arm-static
<lag> Where?
<ogra> (dont extract the deb
<ogra> on a machine of your choice
<ogra> one you can be root on
<lag> I am in a chroot
<ogra> ah, you are in a chroot already
<ogra> k
<lag> Yep
<ogra> is proc mounted ?
<lag> :)
<ogra> update-initramfs needs it
<lag> proc on /proc type proc (rw,relatime)
<ogra> so if you mounted proc and are in the chroot, just dpkg -i the .deb you have
<ogra> that should run update-initramfs from the postinstall script
<lag> I don't want to install it into the chroot
<ogra> why ?
<ogra> its just a chroot
<lag> Because I am on the build server
<lag> The build server has chroot to build in - I don't want to mess it up
<ogra> well, you can uninstall it afterwards
<ogra> k
<lag> Can't I dpkg -i <somewhere else>
<ogra> so: dpkg -x <path to deb> /
<lag> Root?
<ogra> then manually run update-initramfs
<ogra> sure root
<lag> dpkg -x <path to deb> .
<lag> Which I already did
<lag> <lag> Extract kernel.deb
<ogra> after you are done remove /lib/modules/$kver and the files in /boot
<ogra> well, . wont help
<lag> update-initramfs is stupid
<ogra> update-initramfs needs the files in the right places
<lag> ---^
<lag> update-initramfs -b ./boot
<lag> ?
<ogra> its not designed for cross building, its awesome in doing for what it is designed
<lag> Well it should be amended
<ogra> -b will only set the output dir
 * ogra would just install the deb and purge it afterwards
<lag> touch /boot/file
<lag> /usr/bin/touch: cannot touch `/boot/file': Permission denied
<ogra> arent you root ?
<lag> Nope
<ogra> you need to be
<ogra> if you are really that scared to break the build chroot, i'd copy the deb to a local machine and just do it there
<ogra> lol
 * ogra has never seen https://wiki.ubuntu.com/KernelTeam/KernelForIdiots before
<ogra> "The kernel team are geniuses with brains the size of planes ..."
<ogra> HAHAHAHA
<lag> I hope that's not a jaunt on my information procurement!
<ogra> nah
<lag> We all have to learn
<hrw> omg...
<ogra> i just ran across that page
<ogra> the comment not related to anyone in this room
<hrw> I prefer "make-kpkg kernel-image" in git linux tree instead
<ogra> well, but thats not what a buildd does
<hrw> buildd does "dpkg-buildpackage"
<hrw> as it does with other pacakges
<ogra> yeah
<apw> ogra, keybuk is a wag sometimes
<ogra> looking at that page though i wonder if its not also missing the disabling of the module version check
<hrw> after reading that wiki page I think that I need KernelForHrwOrOthersWhichDoNotWantToFollowIdiotsVersion ;D
<ogra> heh
<apw> yeah the naming is somewhat unfortuanate :)
<hrw> ubuntu kernel rules are nice but as long as you do not want to change something ;D
<hrw> those abi, configs etc stuffs
<hrw> for years with debian I just had to do "git pull;make-kpkg kernel_image" to get nice kernel for my machine
<hrw> but this was out-of-debian kernel
<lag> Morning ndec
<ndec> lag: morning
<lag> ndec: How are you today?
<ndec> lag: fine. thx
<lag> ndec: (I'm buttering you up for bad news) ;)
<ndec> lag: that's what i thought ;-)
<ndec> lag: and I think i know what you are going to say next...
<lag> ndec: Have a stab at it ...
<ndec> lag: kernel does not boot.
<lag> Nope
<lag> I haven't got that far
<lag> Or rather, my checks haven't gone that far
<lag> grep ERROR checkpatch.txt | wc -l
<lag> 2820
<lag> 2820 errors in those patches
<ndec> lag: yes, I am reading bryan email...
<lag> Oh, he's sent it already
<ndec> lag: i am trying to understand why we ended up with this...
<lag> ndec: Have you 'brain grep'ed the checkpatch.txt yet
<ndec> lag: how do you 'brain grep', is there a command for this, or perhaps a package ;-)
<lag> Yes, many; emacs, vi, less, cat, kate, gedit, nano, pico ...
<lag> ;)
<ndec> lag: plain grep is quite nice too...
<lag> Yep, well the command I posted above should help
<lag> You still have to 'brain grep' the output
<ndec> lag: i will look into this internally to see what can be done. I will follow up on bryan's email.
<lag> ndec: No problem
<ndec> lag: as of today, this kernel will not boot on your panda, only blaze. which h/w do you have?
<lag> ndec: I'll be waiting to review when the errors (and warnings ;) ) have been corrected
<ndec> lag: well, let's target 11.10, and not 10.10 then ;-)
<lag> ndec: That troubles me a little - there are some patches in there which I need to close bugs (particularly ones from robclark and mythripk)
<mythripk> lag: I guess the patch from me and rob should not cause any issues on panda and can be pulled
<rsalveti> morning
<dyfet> morning is for coffee
<pcacjr> rsalveti: morning
<pcacjr> dyfet: not at all
<rsalveti> lag: did you manage to install the deb package into your chroot and generate the new initrd.img?
<rsalveti> I think you just need /dev and /proc mounted at your chroot
<ogra> dev isnt needed
<ogra> but you need proc
<rsalveti> ogra: I think when installing the package, or generating the initrd.img someone tries to write to /dev/null or something like that
<rsalveti> I had a problem with it in the past, so I generally mount it :-)
<ogra>  /dev/null should be available, debootstrap creates it
<ogra> as well as console
<jkridner1> ds2, all: I can't get passed this error when I try to boot an initramfs (not compiled into the kernel): No filesystem could mount root, tried:  ext3 ext2 ext4 squashfs vfat msdos
<jkridner1> before that, I get RAMDISK: Couldn't find valid RAM disk image starting at 0
<rsavoye> does the ARM have branch delay slots after loads and stores like other RISC architectures ?
<GrueMaster> ogra: Have you looked into why oem-config dies?  I have been trying to figure out what is going on all day yesterday.  What I am seeing is some of the log files in /var/log are corrupted, and mounting the pre-installed image now fails for me (worked on previous images).
<ogra_cmpc> GrueMaster, not beyond what i said already, while it tries to start it dies but you only get the tty back if you hit enter
<ogra_cmpc> and the ubiquity logs only show that it found an already running X server
<GrueMaster> I don't get oem-config at all, just an X background & mouse.
<ogra_cmpc> right
<ogra_cmpc> wait 5min and then hit enter
<ogra_cmpc> oem-config drops you into a root shell if it cant run
<ogra_cmpc> but apparently the console isnt shown unless you hit enter in X
<GrueMaster> Ah.
<ogra_cmpc> how did you shut down before you saw corrupted logfiles ?
<ogra_cmpc> just pull the plug ?
<GrueMaster> Switched to tty0 and did a <ctrl><alt><del>.
<GrueMaster> That triggers reboot.
<GrueMaster> More graceful.
<ogra_cmpc> (the SD card speedup results in less sync calls to write data to disk, if you dont shut down properly it might not have synced the data in cache)
<ogra_cmpc> hmm, a proper shutdown shouldnt result in a corrupted card
<GrueMaster> It should have.  It goes through the normal shutdown this way.
<ogra_cmpc> yes
<GrueMaster> Card doesn't appear corrupted.  e2fsck reports no errors.
<ogra_cmpc> weird
<GrueMaster> But the logs are off.  Mainly Xorg.0.log and a couple of others.
<ogra_cmpc> then i dont get why you see corrupt logs nor why it doesnt mount
<GrueMaster> I'm retrying to I don't have a copy atm.
<ogra_cmpc> the vfat should never be automounted after first boto btw
<GrueMaster> It may have been my desktop.  I had to reboot this morning due to updates.
<ogra_cmpc> *boot
<GrueMaster> I know.  It isn't.
<ogra_cmpc> the rootfs should though
<GrueMaster> That's what I was looking at.
<GrueMaster> But it may have been my desktop.  I'll know more after a bit.  I'm reimaging my SD now.
<ogra_cmpc> k
<GrueMaster>  Looks like I can mount the rootfs on the img file again.  Seriously thinking my desktop had gone south now.
<GrueMaster> weird.
<ogra_cmpc> hmm
<GrueMaster> ogra_cmpc: I thought you had fixed the hostname issue?
<ogra_cmpc> not yet
<GrueMaster> ok
<GrueMaster> Hmmm.  Looks like there was a new ubiquity release after Alpha 3.
<ogra_cmpc> several fixes today, yes
<GrueMaster> today?  I am looking at Aug 6 release.
<ogra_cmpc> hmm
<GrueMaster> Guess I will have to wait.
<ogra_cmpc> i think evan uploaded a slightly broken version before going on vacation
<ogra_cmpc> i saw riddell complain today
<ogra_cmpc> so our brokeness might be related
<GrueMaster> Well, I found an error in the logs.  Went into a shell like you said.  Have a GTKWarning:  Can't open Display.
<ogra_cmpc> i think you should try adding debug-ubiquity to the kernel cmdline
<ogra_cmpc> that should spit out more
<GrueMaster> Will do.
<ogra_cmpc> the two fixes uploaded today were related to python-webkit/-vte dependencies
<ogra_cmpc> might be that we hit the very same issue but dont see the actual error
<GrueMaster> Ouch.  I have a basset hound puppy attacking my bare feet when I try to work on the panda.
<ogra_cmpc> heh
<ogra_cmpc> you got a new dog ?
<GrueMaster> No, he's almost 2 now.  We've had him almost a year.
<ogra_cmpc> ah
<GrueMaster> But I put a blanket for him under my side desk that has the panda & dove work spaces.
<GrueMaster> And he has huge paws.
<lag> Does anyone know how to mount HDDs once in a schroot?
<ework> mattman, so I got ubuntu working
<ework> mattman, I got ubuntu 10.04, 10.10, and linaro all working using your kernel and the stock kernel from ARM.  What I was missing was to setup ttyAMA0 for login so I had no idea it was working.  I wrote some bullets of how I got 10.04 on the board that I would like to add to the wiki but they are kind of crude right now.
<GrueMaster> lag: make sure to mount none /dev -t devtmpfs for the drives to show up.  Then they should mount.
<lag> GrueMaster: bingo!
<lag> GrueMaster: Phew! Thanks for that
<GrueMaster> np.
<lag> Are there any scripts which are run on entry to the schroot - I'd like to place that line in there
<lag> Or is it okay to put it in the fstab?
<GrueMaster> I think that is done by init on boot normally.
<lag> Oh, so when I restart my machine, it will just work?
<lag> I can't see that myself :)
<GrueMaster> it should just work on boot.  Running a chroot environment is a bit different.
<lag> Phew!
<lag> The answer:
<lag> In /etc/schroot/mount-defaults:
<lag> /home/lag   /home/lag	 none	rw,bind	    0       0
<lag>  /dev            /dev             none   rw,bind     0       0
<lag> :D
<mattman> ework: sorry, stepped away for a moment. glad to hear your up and running.
<ework> mattman, I was working on cleaning up my instructions on installing ubuntu 10.04 so I can post them on the wiki.  I already logged in through launchpad so it looks like I have edit permissions
<mattman> ework: great, i'll be looking for your additions.
<hrw> I love oom on c3
<hrw> need to finally dist-upgrade it to fresh maverick
<hrw> it is amazing how slow beagleboard C3 is when nothing runs on it + ssh session
<hrw> nothing = NM+dbus+wpa-supplicant+modem-manager
<rcn-ee> hrw, put a nice fast usb harddrive with some swap.. ;)
<hrw> rcn-ee: such bare system should fit in 256MB ram
<hrw> and 0.5GB swap is on pata hdd on usb
<ework> mattman, have you been able to get X working?
<ework> mattman, the instructions I'm working on now is just getting the base system up and running
<mattman> ework: i am using mostly the base system also
<rsalveti> GrueMaster: didn't generate the kernel with the reclaim-related patches yet because they require more patches that are at the akpm's tree
<rsalveti> GrueMaster: and the original author is still discussing the patches upstream
<ework> mattman, I suppose it should work with some form of framebuffer driver but haven't looked into that yet.  I did and apt-get of ubuntu-desktop after the base system was up.
<rsalveti> once we get the patches upstream, or at least organized at an important tree, we can try to see if get any improvement on arm
<rsalveti> then we can request the kernel people to look at it
<mattman> ework: let me know how it goes for you, my initial tests with X was the output was very "jittery"
<mattman> ework: i didn't dig very far to see what was going on.
<rsalveti> GrueMaster: as it helps a lot on the desktop side (it seems), I guess they'll probably accept the patches without many effort
<rsalveti> accept to do the backport
<ework> mattman, ok done with my instructions now lets see about pasting them in
<lag> Grrrr
<rsalveti> lag: still working?
<lag> rsalveti: http://paste.ubuntu.com/476578/
<lag> rsalveti: Only when I'm awake :)
<rsalveti> lag: :-)
<rsalveti> lag: you can ask dpkg to force the installation
<lag> Will it affect the initrd.img?
<rsalveti> lag: wireless-crda? don't think so
<rsalveti> lag: ./rootstock --fqdn panda-maverick --login ubuntu --password ubuntu --serial ttyO2 --components "main universe multiverse" --kernel-image http://rsalveti.net/pub/ubuntu/kernel/maverick/linux-image-2.6.34-903-omap4_2.6.34-903.7rsalveti2_armel.deb
<GrueMaster> rsalveti: Ok
<rsalveti> lag: this is how I generally create a new rootfs with a new kernel
<lag> I don't want a new rootfs
<rsalveti> then I just write the rootfs, generate the uI* files and copy to my sd card
<lag> I want to use the daily image's rootfs
<lag> It's the whole point for me jumping through these hoops :)
<rsalveti> lag: oh, true, the bug that only happens with the daily image
<lag> That's the idea
<prpplague> rsalveti: ping
<rsalveti> prpplague: pong
<prpplague> rsalveti: you have an asound.conf file for blaze/sdp4430 ?
<rsalveti> prpplague: can check on my panda, but not sure
<prpplague> rsalveti: you have the audio working properly on your es1.0 panda?
<rsalveti> prpplague: never tested
<rsalveti> GrueMaster: ^?
<rsalveti> who needs sound anyway hehe
<prpplague> rsalveti: hehe
<rsalveti> maybe GrueMaster tested it already, as he tested quite many things already for panda
<prpplague> rsalveti: is there a tested rootfs posted somewhere?
<rsalveti> prpplague: there is the pre-installed image that you can test, if you want
<prpplague> rsalveti: url?
<rsalveti> prpplague: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
<prpplague> thanks
<rsalveti> was finding it :-)
 * prpplague looks
<rsalveti> the alpha 3 image, if you prefer http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/alpha-3/
<prpplague> holy cow
<prpplague> 500meg
<rsalveti> just dd it at your sd card and boot it
<rsalveti> yep, lots of packages
<rsalveti> prpplague: and pick a 4gb sd card :-)
<prpplague> rsalveti: oh, it's not a tarball?
<rsalveti> prpplague: nops
 * prpplague cancels download
<rsalveti> you can generate a rootfs with rootstock if you want
<rsalveti> and then used it at your device or chroot
<rsalveti> but it's a lot of work for just trying to find a simple file :-)
<prpplague> hmm
<prpplague> either way it is a pain
<prpplague> rsalveti: my biggest rootfs is 16meg
<ework> mattman, ok saved
<ework> mattman, let me know what you think and make any corrections or clarifications you think are needed
<mattman> ework: thank you, i'll take a look at them.
<rsalveti> prpplague: no sound
<rsalveti> doesn't seems to work by default
<ework> mattman, the instructions are somewhat generic and could apply to a number of development boards in some places
<rsalveti> not with pulseaudio at least
<prpplague> rsalveti: oh
<rsalveti> hm, let me check if I'm getting something from the hdmi output
<prpplague> rsalveti: are you guys testing with blaze and sdp as well?
<rsalveti> prpplague: I know ogra_cmpc have one blaze, but don't know if he is testing the image on it or not
<prpplague> hmm ok
 * prpplague wonders who at ubuntu-arm is responsible for the audio testing
<prpplague> its kinda like no one is using audio with omap4
<hrw> prpplague: remember that this is #ubuntu-arm not #angstrom - here devs generate 0.5GB images as base ones
<prpplague> yea
<rsalveti> hrw: we'll have a real base one later on
<ogra_cmpc> prpplague, audio should work fine via HDMI
<ogra_cmpc> and if you need an asound.conf file thats a bug with the compiled in defaults, audio should just work, i'm aware that we have to still do some work here
<ogra_cmpc> pulse as well as the kernel defaults for the asoc driver will still need to be touched
<ogra_cmpc> rsalveti, persia is tasked with fixing pulse as soon as he comes back online
<ogra_cmpc> (he just moved houses and seems to have some connection issues)
<rsalveti> ogra_cmpc: hm, ok
<ogra_cmpc> it needs a special config
<mattman> ework: thanks for making those additions, they are very helpful
<ework> mattman, glad you appricate them :)
<ndec> prpplague: do you have /sys/devices/platform/soc-audio on your panda?
<rsalveti> ogra_cmpc: and with blaze, did you tested it already?
<rsalveti> don't know if we also have speakers at blaze
<ogra_cmpc> we dont iirc
<ndec> rsalveti: ogra_cmpc: we have audio on blaze, but it requires proper asound.conf, and a couple of changes in pulse config
<prpplague> ndec: yea
<ogra_cmpc> ndec, the same pulse changes we need for panda, right ?
<ndec> prpplague: so at least, all drivers are compiled in. you will only be missing the ascound.conf
<ogra_cmpc> if you need an asound.conf something is wrong
<ndec> ogra_cmpc: yes. same changes (it's basically to tell pulse to use fixed point resampling, instead of floating point)
<ogra_cmpc> right
<prpplague> yea, i just wanted to make sure i have the correct things turned on for the headset
<ogra_cmpc> thats on persias list
<ndec> ogra_cmpc: well... this, I am not sure. audio h/w pieces is quite complex on OMAP4, and I am not up to speed with this.
<ndec> prpplague: so you never tried audio on panda (i mean on the headset)?
<ogra_cmpc> ndec, well, if you need an asound.conf it means you need to override a default, the default should always work
<prpplague> ogra_cmpc: you have _any_ audio working on any omap4 ?
<prpplague> ndec: yea i have had the audio working on earlier L24.x kernels
<ogra_cmpc> prpplague, iirc we had working audio via HDMI on the panda in prague
<prpplague> ogra_cmpc: yea, the hdmi audio seems to be working fine
<ndec> prpplague: did you grep is4430 is the audio driver code?
<ogra_cmpc> and i think the panda kernel (falsely?) defaults to the HDMI device
<ndec> prpplague: /is4430/is4430sdp/
<ogra_cmpc> on the panda the default should be the headphone jack imho
<ogra_cmpc> while on the blaze hdmi might make more sense
<ndec> ogra_cmpc: do you needs what needs to be done for ubuntu sound preference to figure this out, and allow configuration?
<ogra_cmpc> i didnt play with it yet but shouldnt be to hard to figure out
<prpplague> ogra_cmpc: _shouldn't_  , but i'm working with a new kernel build with a ton of changes
<rsalveti> GrueMaster: still there?
<GrueMaster> yes, I'm here.  Didn't see the earlier posts until now.
<prpplague> rsalveti: found the problem anyway, thanks
<rsalveti> GrueMaster: http://rsalveti.net/pub/ubuntu/kernel/maverick/linux-image-2.6.34-903-omap4_2.6.34-903.7rsalveti2_armel.deb
<rsalveti> GrueMaster: the deb file with latest kernel plus some patches from robclark to improve the dvi support
<rsalveti> if you want to test
<rsalveti> mine doesn't work because I'm getting -vsync with my monitor
<rsalveti> prpplague: np, did you create a new asound.conf?
<GrueMaster> I do, but it may be a little while.  I'm trying to either resolve the oem-config issue or will file a bug shortly.
<prpplague> rsalveti: yea, manually
<rsalveti> GrueMaster: np, just to let you know about if, if you're willing to test :-)
<rsalveti> *it
<rsalveti> prpplague: is it working at the headset output for you now?
<GrueMaster> That's what I'm here for.
<prpplague> rsalveti: yea
<rsalveti> nice, good to know that it works :-)
#ubuntu-arm 2010-08-12
<ework> mattman, ok X works it just doesnt seem to like using a DVI to VGA adapter also since its using a framebuffer you can't change the resolution
<ework> mattman, added some minor changes about the framebuffer device node and using DVI directly which fixes my X11 problems
<ework> mattman, should be sufficient now for someone to get an ubuntu desktop running on that board
<mattman> ework: so what are the parameters you're passing into the frame buffer?
<ework> nothing just created the device node
<ework> it works at 1024x768x60 without any changes
<mattman> ework: that's good to know
<ework> mattman, yah there should be enough tips and instructions there now to get ubuntu 10.04 installed from scratch
<ework> mattman, to the desktop
<mattman> ework: great
<ework> mattman, thanks for your help I wouldn't have gotten this far without your pointers
<GrueMaster> Great.  Now I am seeing soft lockups on cpu0.  Very frustrating
<cooloney> hquit
<rsalveti> GrueMaster: with beagle or panda?
<prpplague> the beanda
<prpplague> evening folks
<GrueMaster> rsalveti: Panda.  And I'm out for the night.
<rsalveti> GrueMaster: with the latest kernel?
 * rsalveti also needs to get some sleep :-)
<GrueMaster> Not sure.  20100809 build + updates.  Not your kernel.
<GrueMaster> Had to update to get the latest oem-config before filing a bug against it.
<rsalveti> GrueMaster: hm, because 2.6.34-903-omap4 should be our latest
<rsalveti> and we got an update to this version days ago
<rsalveti> so it could be a regression
<GrueMaster> I think 902 is on the image.  Not sure what was pulled with the update.
<lag> mythripk: ping
<mythripk> hi lag
<lag> Hey :)
<lag> I'd like to pull your (and robclark's) patches to make my Panda work
<lag> What commit shas do I need?
<lag> mythripk: ?
<mythripk> lag : do you want me tosend
<mythripk> the commit id's of mine and rob's patch ?
<lag> mythripk: Yes please
<mythripk> 1 sec
<lag> Thank you
<mythripk> http://dev.omapzoom.org/?p=axelcx/kernel-display.git;a=shortlog;h=refs/heads/display-next
<mythripk> from  commit 0ec1de9609d2b42bf47f63f9e8a4a50de30b381e- Patch to Enable autodetect with EDID in HDMI
<mythripk> to b128c1648c6f0d39645f0424ac45a5c5b848bcc0 HDMI:Move the functions from HDMI Irq handler to work queue
<ogra> grmpf
<lag> mythripk: Just those too?
<mythripk> entire set from the first commit
<mythripk> to the last one in that path
 * ogra whacks d-bus
<ogra> why the heck do i get an exec format error running a python app ... damned
<amitk> ogra: stop compiling python apps :-p
<ogra> amitk, heh, tell that to the oem-config guys
<ogra> i dont think its python spilling the error but a subprocess it calls
<ogra> GrueMaster, do you have any beagle that boots the current image ?
<ogra> GrueMaster, so that you could test if oem-config fails the same way on omap3
<GrueMaster> ogra: I had it doing upgrade testing, but will try it today.
<GrueMaster> Also, I had already filed a bug yesterday on oem-config yesterday.  Bug 616581.
<ubot2> Launchpad bug 616581 in ubiquity (Ubuntu) "oem-config fails to run (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/616581
<lag> ndec: Hi
<rsalveti> lag: http://gitorious.org/ubuntu-experimental/kernel-maverick/commits/rsalveti-ti-omap4
<rsalveti> the patches I'm using for the monitor issue
<rsalveti> the 9 patches I got from mythripk plus some more from robclark that I got to test the dvi support
<rsalveti> lag: do you have any plan to merge any of these patches?
<rsalveti> I know you have a similar monitor :-)
<lag> rsalveti: We have plans to
<lag> rsalveti: I'm looking at it right now
<lag> rsalveti: They should be in there by Testy Tiger
<GrueMaster> lag: I hope you aren't referring to an ubuntu release by that name.
<lag> GrueMaster: Yep
<rsalveti> haha
<GrueMaster> Jesh.  You aussies are slow... :P
<lag> =:-D
<lag> GrueMaster: Don't make me get personal
<GrueMaster> heh
<rsalveti> lunch time :-)
<lag> The TI tree is a bit of a mess
<lag> We're discussing how we should move forward currently
<GrueMaster> Bah.  Today's omap4 image hangs past checking rootfs with no indicators.
<ogra_cmpc> worked for me
<GrueMaster> sigh.
<lag> These things always work for the person how develops them ;)
<ogra_cmpc> well, i didnt do anything specific
<ogra_cmpc> the image behaves the exact same way for me as yesterday
<ogra_cmpc> (which was the 09 image i tested)
<GrueMaster> And the omap image fails oem-config.
<ogra> GrueMaster, ok, thanks, thats what i wanted to know
<ogra> can you check in the rootshell if dbus is running for you ?
<GrueMaster> I see dbus-daemon --system --fork in the ps ax output.
<ogra> weird
<ogra> i dont on omap4
<GrueMaster> My omap4 doesn't get very far, unfortunately.
<ogra> do you see anything in 7var/crash ?
<GrueMaster> ubiquity-dm
<ogra> only that ?
<ogra> i got some more files there on omap4
<GrueMaster> My omap4 doesn't appear to have actually mounted rootfs.  Last item is :
<GrueMaster> fsck from util-linux-ng 2.17.2
<GrueMaster> /dev/mmcblk0p2: clean, 155074/1858304 files, 536382/3895762 blocks
<ogra> thats after first reboot ?
<GrueMaster> yes.  First boot succeeds.
<ogra> very strange
<GrueMaster> Between boots, I have to stop and fix boot.scr to get video.  But it is the same settings I have always used, so I don't think they have any influence.
<ogra> nah, shouldnt
<GrueMaster> And I checked.  Both today's and 0809 have the same kernel.
<GrueMaster> (it would be nice to have a manifest to do full image comparisons - hint hint).
<GrueMaster> ogra_cmpc: Rebooted panda.  Now I get X (still no oem-config).  Not sure why it started hanging like this.  Works fine with the Alpha 3 image.
<GrueMaster> Now it just hands randomly with today's image, or 0809 image manually updated.
<prpplague> GrueMaster: you doing any audio on the panda?
<GrueMaster> prpplague: Not yet.  Still working on gettng a stable image.  I can go back to Alpha 3 and do more testing there.
<GrueMaster> ogra_cmpc: What would I file a bug against to note that the linux-headers-omap4 are not installed on the omap4 image?  We have omap, dove, and imx51, but no omap4.
<rsalveti> GrueMaster: the package is there, do you know who should depend on it?
<GrueMaster> Not really.  I know the package is there.  Also, I am running the Alpha 3 image at the moment and doing an update, but it doesn't see the linux-image-2.6.34-903-omap4_2.6.34-903.7_armel.deb kernel as an upgrade option, even with dist-upgrade.
<GrueMaster> And today's image isn't using it either.
<rsalveti> GrueMaster: yep, that's what I saw now
<rsalveti> the new package is there but the package linux-image-omap4 is depending on the older one
<rsalveti> Depends: linux-image-2.6.34-902-omap4, linux-firmware
<rsalveti> that should be the reason
<GrueMaster> yea, that would be it.  sigh
<rsalveti> now we need to know why it was not updated with the kernel update
<rsalveti> hm, is just the meta package
<GrueMaster> yes.  But why isn't it getting updated?  Or is it stuck in the build queue?
<rsalveti> GrueMaster: could be
<GrueMaster> Looks like 903.7 was built on the 7th.  Should have had a meta package by now.
<rsalveti> GrueMaster: but the meta package wasn't updated with the kernel package
<rsalveti> or should it be automatically updated?
<GrueMaster> Not sure.  Something for the kernel team.
<rsalveti> let me try to understand how it works
<rsalveti> argh, and we had the new kernel days ago and because of this you're testing an older version =\
<GrueMaster> yep.
<GrueMaster> Of course the images, while building, are currently broken due to bug 616581.
<ubot2> Launchpad bug 616581 in ubiquity (Ubuntu) "oem-config fails to run (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/616581
<GrueMaster> Which is why I am running A3 and updating.  Very slowly updating.
<rsalveti> yep, but at least the kernel issues you got could be fixed already
<rsalveti> tell me about it
<rsalveti> that's why for development I'm using a external usb hd
<GrueMaster> usb HD is faster than the SD?
<GrueMaster> I hadn't benchmarked it.
<hrw|gprs> on omap3?
<rsalveti> panda
<hrw|gprs> probably same
<rsalveti> it seems faster
<hrw|gprs> on omap3 you get 5MB/s read from sd and 14MB/s from same sd in usb card reader
<rsalveti> ouch
<hrw|gprs> thats from my tests on beagleboard
<GrueMaster> I don't think the drive is the limiting factor.  Pulling updates from ports.ubuntu.com is slow on a good day.
<hrw|gprs> and I have 0.5$ worth card reader
<GrueMaster> Sounds like something plars could look into.  He's into performance issues.
<plars> I am?
<GrueMaster> I'm mainly concerned with functionality atm.
<GrueMaster> I thought that was your focus this cycle.
<plars> hrw|gprs: that's interesting, haven't looked at it personally though
<plars> GrueMaster: technically, my focus is tools
<GrueMaster> ah.
<plars> which got turned into s/tools/infrastructure
<GrueMaster> heh.
<plars> would be a good thing for the landing teams to look at
<plars> it makes me wonder what the results of the same test would be on dove or babbage
<plars> and others
<plars> is this an arm thing, or a beagle specific thing
<GrueMaster> Right now, I am more concerned with getting a working image.  How fast it fails is irrelevant.  :P
<hrw|gprs> arm or omap3 or a beagle
<hrw|gprs> I have to check one day how fast beagleboard is with my 1.5TB sata harddrive when it is on usb bus.
<hrw|gprs> over sata it does 110MB/s, over usb with sheevaplug it did 30MB/s without problems
<plars> hrw|gprs: what are you testing with?
<hrw|gprs> it was simple 'hdparm -tT'
<hrw|gprs> on beagle I used dd
<GrueMaster> rsalveti: omap4 meta package is being looked into.
<rsalveti> GrueMaster: yep. ot
<rsalveti> it's missing an update
<rsalveti> I'll forward it to tgardner
<GrueMaster> helps having two kernel crunchers in my town.
<rsalveti> I'm just updating it and will send to the kernel devs
<rsalveti> argh, some io is killing my machine
<rsalveti> and pulse get stuck everytime
<hrw|gprs> but if you give me armv4t rootfs then I can do any set of strange tests
<rsalveti> GrueMaster: ogasawara is updating the linux-meta package
<rsalveti> we should get it updated soon
<GrueMaster> rsalveti: I know.  I have a back channel to her and others in Portland.  But thanks.
<rsalveti> GrueMaster: oh, you cheated
<rsalveti> :-)
<GrueMaster> Of course.
<GrueMaster> Something I learned at Intel.  It is sometimes easier to use back channels to get things done quickly.
<rsalveti> GrueMaster: sure
<rsalveti> the kernel seems to be a little mess
<rsalveti> you have to update the kernel and also update the meta package
<rsalveti> they are at a git tree, and not bzr, so merge proposals don't basically work
<rsalveti> and the meta package is with a wrong version
<rsalveti> and wrong description
<rsalveti> GrueMaster: at tomorrow's image you'll get the latest kernel :-)
<GrueMaster> Yes, I know.
<rsalveti> with new fixes and hopefully without any other new bug
<rsalveti> :-)
<rsalveti> GrueMaster: yeah, why I'm talking with you, you must be cheating again
<rsalveti> :P
 * rsalveti starts looking for his beagle xm
<rsalveti> GrueMaster: do you know what is the memory chip that we have issues with xm?
 * rsalveti now needs to find about the xm known issues
<GrueMaster> I think it is a kingston, but not sure.  I don't have an XM yet (next week).
<GrueMaster> rsalveti: Have you seen the issue with panda where the sd interface shuts down?  I have this message:  INFO: task mmcqd:46 blocked for more than 120 seconds. followed by other blocked tasks.
<GrueMaster> And it appears to be SD related.
<GrueMaster> I have mouse, but no keyboard.  That means the USB is semi-functional.
<rsalveti> GrueMaster: hm, never saw it
<rsalveti> GrueMaster: how do you generally hits this issue?
<GrueMaster> I was running apt-get update.  Just stopped during logrotate upgrade.
<GrueMaster> Unfortunately there are no log entries and nothing on serial console (beyond what I posted).
<rsalveti> hm
<rsalveti> GrueMaster: are you updating from alpha 3 to current?
<rsalveti> if you can reproduce it, we could try with 903
 * GrueMaster patiently waits for the beagle to finish updating the highly needed voodo graphics drivers and other X drivers.
<rsalveti> lol
 * rsalveti hates that
<GrueMaster> I plan on it.   Unfortunately, reproducing these types of bugs can be problematic at best.
 * GrueMaster wonders if his flyswatter would be useful in this situation.
<GrueMaster> mpoirier: Cool find on the mtd support issue for beagle.  Let me know when you have a kernel you need me to test.
<mpoirier> GrueMaster:  Ok, I'll compile something toghether...
<rsalveti> ahh... coffee
<rsalveti> GrueMaster: http://gitorious.org/pandaboard/u-boot/commits/omap4_panda_es2.0
<rsalveti> GrueMaster: http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_es2.0
<GrueMaster> rsalveti: Thanks.
<rsalveti> http://gitorious.org/pandaboard/kernel-omap4/commits/L24.8_panda_es2.0
<GrueMaster> New kernel as well?
<prpplague> GrueMaster: yea, it adds the EHCI support
<rsalveti> hm
<rsalveti> GrueMaster: I can grab the patches and generate a deb file for you, if needed
<mpoirier> GrueMaster: http://people.canonical.com/~mpoirier/linux-image-2.6.35-15-omap_2.6.35-15.22_armel.deb
<rsalveti> I have my dev environment setup already
<rsalveti> GrueMaster: at least for kernel
<GrueMaster> rsalveti: I have a pbuilder environment on my dove.  Decently fast native builds.
<GrueMaster> mpoirier: Thanks, will test today.
<rsalveti> GrueMaster: cool, so np :-)
<mpoirier> dyfet: is https://bugs.launchpad.net/bugs/b608279 still valid ?
<mpoirier> GrueMaster: do you know anything about  https://bugs.launchpad.net/bugs/608279
<GrueMaster> mpoirier: That was based on some really early testing I did with read-edid.  dyfet should be actively involved with this issue.
<mpoirier> GrueMaster: I was able to read the EDID from u-boot.
<mpoirier> what user space tool did you use ?
<GrueMaster> read-edid.
<mpoirier> ok, I'll try.
<GrueMaster> mpoirier: See https://blueprints.launchpad.net/ubuntu/+spec/mobile-m-omap-edid-autodetection.
<mpoirier> got that thanks.
<GrueMaster> rsalveti: I think you will need to build the required files.  I am not setup for this type of build.  I am setup for package building.
<rsalveti> GrueMaster: np, I just wanted to know the es2 specific patches so I can put it my ubuntu tree for the moment
<rsalveti> and build the package like any other ubuntu tree
<rsalveti> let me take a look at it
 * GrueMaster needs a break.
#ubuntu-arm 2010-08-13
<rsalveti> GrueMaster: still building, soon you'll get it
<GrueMaster> No rush.  I've started packing for my flight tomorrow.  I'll test first thing Monday once I'm setup.
<rsalveti> GrueMaster: oh, are you leaving tomorrow?
<GrueMaster> I'm feeling rather bushed and my son is down for the weekend to celebrate his 21st birthday with his friends.
<GrueMaster> I fly out tomorrow morning.
<rsalveti> GrueMaster: quite soon :-)
<rsalveti> well, it's a long flight for you
<GrueMaster> 13 hours or something like that.
<rsalveti> hm, about the same for me if I'd go there
<rsalveti> talking about trips I need to book my uds trip
<rsavoye> where's UDS going to be this time ?
<rsalveti> orlando
<rsavoye> yeuch
<rsavoye> dates ?
<rsalveti>  25th - 29th October
<rsavoye> thanks. I know some nice place in Colorado we could have it...
<rsavoye> I thought I saw a new kernel get uploaded today ?
<rsavoye> still trying to get my XM board to work stably...
<lag> cooloney: Morning
<mopdenacker> ogra: Hi! I started testing your
<mopdenacker> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100812/maverick-preinstalled-netbook-armel+omap4.img.gz image
<mopdenacker> on my PandaBoard ES 1.0.
<mopdenacker> I get the below error message after the reboot:
<mopdenacker> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100812/maverick-preinstalled-netbook-armel+omap4.img.gz
<mopdenacker> Oops, here's the error: http://pastebin.com/iKWD7Umg
<cooloney> lag: morning man
<lag> cooloney: Hey Bryan
<lag> cooloney: How are you getting on with your packaging work?
<cooloney> lag: yeah, just rebased to our 2.6.35 master tree
<cooloney> and sent out an email to discuss the maintanenc method
<cooloney> lag: how about your review?
<cooloney> i think ndec is still working on the integration tree, since there L24.9 branch is increasing
<mopdenacker> ogra: I wonder what's responsible for the "Exec format error" message.
<lag> cooloney: Yes, I saw your email
<lag> cooloney: I was chatting with apw and tgardner yesterday about the maintenance issues
<lag> cooloney: It's quite a complex one
<lag> cooloney: It would be easier if TI's tree was based solely on Linus' 2.6.35 tree
<cooloney> lag: right, i also asked that question in the email to ndec
<cooloney> lag: but that's TI's internal process. i hope we can get such ti patch stack on Linux 2.6.35 release
<cooloney> lag: currently, it is not easy for them to change.
<lag> cooloney: How did you do the last one?
<cooloney> lag: sorry, what's the last one?
<lag> The last release
<cooloney> oh, the last release is simpler, since we just rebased TI's 230+ patches on top of our tip tree.
<lag> So what makes this any different?
<cooloney> lag: actually no big difference to me, just 1300+ patches vs 230+ patches.
<cooloney> and it is 2.5.35 based release
<cooloney> we cannot simple rebase on our -ti-omap4 branch, but need to rebase on our master
<cooloney> since our master is also 2.6.35 based
<lag> When I do a git merge onto master, I only receive one (easily correctable) issue
<cooloney> yeah, that's it.
<cooloney> i got 2,
<cooloney> today.
<cooloney> but 2 of them are omap3 related
<cooloney> so it won't be much difficult.
<cooloney> apw's method is not necessary this time
<lag> You have to revert ce8bd5fb89ad58d345a5eaef52e7fa6f5683f5a9
<lag> Then you only get one
<lag> cooloney: -^
<cooloney> lag: thx, man, you fixed 50% rebasing issues
<cooloney> lag: and as ndec said in his latest email, we still need to wait for their integration release
<cooloney> that's our upstream, L24.9 is just their monthly release tree.
<lag> Well, why don't we wait then?
<lag> I'm guessing sebjan will ensure their tree _fits_ on ours
<lag> cooloney: The other conflict should be easy too
<lag> cooloney: The one in HEAD looks far more correct than the other
<lag> Just delete
<lag> =======
<lag> 	dss_clk_enable();
<lag> 	r = dsi_pll_init(dssdev, 0, 1);
<lag> >>>>>>> L24.9
<lag> and obviously <<<<<<< HEAD
<lag> The result of the successful merge can be found here: http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4-35
<lag> Now I just need your packaging work to test
<cooloney> lag: how did you do that? git merge?
<lag> cooloney: Yeah
<cooloney> lag: i found you missed some patches from L24.9 branch
<lag> Oh?
<lag> When were they released?
<lag> Give me the commit ids
<cooloney> lag http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.9
<cooloney> they updated their tree yesterday, i think
<cooloney> the release for us is supposed to be next week.
<cooloney> ndec and sebjan will work on it.
<cooloney> please find my rebase result here
<cooloney> http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-release-rebasing-testing
<lag> cooloney: I didn't miss anything - they weren't in the tree then
<lag> I thought it was for Friday?
<lag> cooloney: It's pointless merging now, they are going to be updating it daily
<lag> We should wait until our proper release date
<cooloney> lag: right, we have to wait
<lag> ndec: Are you there?
<cooloney> so i just test rebasing is simple for this release
<lag> cooloney: Me too
<ndec> lag: hi!@
<lag> ndec: Hello :)
<lag> We've been discussing how best to handle your tree
<ndec> lag: oh i see... i saw the emails but was not watching irc...
<lag> When it our release date?
<lag> is*
<ndec> lag: cooloney: the current l24.9 branch is quite broken, especially on panda, we are trying to fix this.
<lag> ndec: Do you have people working on the checkpatch errors too?
<ndec> lag: unfortunately, I will be on vacation next ;-)... but sebjan will come back mid of next week.
<ndec> lag: for checkpatch, this is a bit more complicated...
<ndec> lag: our dev process implies that our dev teams are moving to .36, so very likely they will not addess them in a .35 release.
<cooloney> ndec: after a quick review of the checkpatch result file, i think just several patches cause most of errors
<ndec> lag: i will need to see what we can do with sebjan for the most critical one
<cooloney> ndec: if we pointed them out, they can help to fix that in .36
<ndec> cooloney: well .36 won't help since we will stay in .35. but since you have the list already, you can send that to me and sebjan and we can address them
<cooloney> ndec: yeah, i know that. but i don't think we can fix those 2800++ coding style errors in this release.
<lag> ndec: Would it be possible to insure your developers run checkpatch before applying their work in future
<cooloney> just wanna let them know this.
<ogra_cmpc> mopdenacker, i wish too i would know that, we're hunting this bug since monday
<ndec> cooloney: lag: we are working on this...
<ndec> cooloney: lag: they know.
<lag> ndec: If you every want to upstream your code, it will have to become a common operating procedure
<ogra_cmpc> mopdenacker, if you want a working install, use the alpha3 milestone image
<mopdenacker> ogra_cmpc: thanks. That's good to know that I'm not the only one...
<cooloney> ndec: actually, i think for TI git server we can add some git post-commit script which will call checkpatch.pl to check every commit
<mopdenacker> ogra_cmpc: OK, I will do that. Thanks!
<ndec> lag: it's part of the procedure. the main problem is time pressure and h/w problems that we need to work with
<lag> ndec: Don't we all :)
<cooloney> ndec: technically it will drop those commit having coding issues
<ndec> cooloney: we know all of this...
<lag> ndec: :D
<ndec> lag: yes we do. then it's a matter of prioritization ;-)
<cooloney> ndec: right, i understood
<lag> ndec: Indeed
<lag> ndec: When is your release date?
<ndec> lag: at the end of the day we make h/w... and this is much less soft than software ;-)
<cooloney> ndec: i agree the first thing we need is working stable 2.6.35 based release for both panda and blaze
<ndec> lag: on 17th we should get an updated BSP
<lag> So we'll pull your tree then?
<ndec> cooloney: they have been some updates this night in L24.9 branch. I still haven't had a chance to build, but they are supposed to have fix the panda boot problem.
<lag> rcn-ee: ping (when you're up)
<lag> ndec: cooloney: We should wait until the release date
<cooloney> ndec: got it, awesome. need any help, please let use know
<lag> ndec: cooloney: It's pointless merging until it's finished
<ndec> lag: for this specific release where our dev team release is on .35, yes, you can pull from L24.9 branch. then we will create a stable branch on http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=summary for the updates
<cooloney> lag: yeah,
<lag> ndec: And when's that due?
<cooloney> ndec: indeed. that's way we worked for several monthes
<lag> cooloney: When will your packaging be finished?
<ndec> lag: agreed. it's pointless untill I or sebjan tells you that it's booting on panda and blaze, let us do the dirty stuff first ;-)
<cooloney> lag: i have to wait for that release
<ndec> lag: final L24.9 branch from dev team due on 17th
<lag> ndec: I have every intention :)
 * ogra_cmpc hands ndec some gloves
<lag> ndec: Noted
<cooloney> lag: need to sync config files with the latest release.
<ndec> ogra_cmpc: for this specific item I will be on vacation ;-), so I am passing the gloves to sebjan
<lag> ogra_cmpc: Why? Do you have something stuck up there which you'd like removing?
<ogra_cmpc> ndec, haha
<ogra_cmpc> lag, no, for not getting his hands so dirty
<lag> ogra_cmpc: ;)
<cooloney> heh
<ogra_cmpc> lag, i'm well able to remove stuck things myself :P
<lag> ogra_cmpc: Comes with practise I suppose :)
<lag> ogra_cmpc: Where should the jasper.log file be?
<ogra_cmpc> lag, after the install run in /var/log, during initramfs in /dev/.initramfs/
<ogra_cmpc> (jasper copies it over as the last step before the reboot)
<lag> It's not in /var/log
<ogra_cmpc> then check /dev/.initramfs/
<ogra_cmpc> (if it still exists)
<lag> ogra_cmpc: http://paste.ubuntu.com/477403/
<lag> Does that look okay to you?
<lag> ogra_cmpc: My Panda comes to a crashing halt when the purple screen appears
<lag> The cursor and the background is visible but nothing else
<ogra_cmpc> hit enter after waiting a few mins
<lag> And my USB mouse and keyboard no longer work
<ogra_cmpc> i suppose you are using a newer image than A3 ?
<lag> I am using the latest daily build
<ogra_cmpc> oem-config dies for no apparent reason since monday
<lag> Okay
<lag> What's the link to the most stable version?
<ogra_cmpc> take A3
<ogra_cmpc> http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/
<lag> I have it
<rcn-ee> lag pong. ;)
<lag> Good morning Robert
<rcn-ee> Hi Lee, how's it going.
<lag> Are you well?
<lag> Very good thanks
<lag> Have you heard anything regarding your ro patch?
<rcn-ee> i'm good, it's friday.. ;)  I need to quickly verify on my C2/C4 before i post version 3... (it'll be this afternoon as i get off at noon)
<lag> Are you going to shift all the code to board-omap3beagle.c on v3?
<rcn-ee> yeap i did..
<lag> Good stuff
<lag> Hopefully they're leave you alone on this one
<lag> What happens once it's been approved on linux-omap?
<lag> Do you have to submit it upstream?
<rcn-ee> nah i'm not woried. ;) they are here for reference.. http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.35-devel/files/head:/patches/gpio/
<rcn-ee> after linux-omap, tony will probally push them for 2.6.37... (in for-next)  (the 2.6.36 merge can't last for maybe another day or two..)
<ogra> ndec, can you include asac in the invite for the friday call ?
<lag> rcn-ee: Is Tony the linux-omap maintainer?
<amitk> lag: he is
<amitk> lag: want to meet him?
<lag> Sure, why not!
<amitk> lag: come to Helsinki on Tuesday, I'm having lunch with him
<lag> amitk: Not that I have anything to say :)
<lag> amitk: I'll just nip over :)
<rcn-ee> Yeap Tony is the linux-omap maintainer..
<amitk> rcn-ee: how are your stocks of XMs? :)
<rcn-ee> rumor up the grape vine... possibly next week..  but i'll probally say that again next week.. ;)
<lag> rcn-ee: You can have mine when amitk sends me the new version :)
<rcn-ee> i'll trade you my 256 xMA P7 for your 512. ;)
<rcn-ee> even  thou the 512's have memory problems, they stay up longer then my 256. ;)
<lag> rcn-ee: I'll think about it
<lag> rcn-ee: nah
<ogra> lag, you are not seeing Bug 605488 because we dont use swap currently, create a swapfile and add it to fstab, then see if you get the errors
<ubot2> Launchpad bug 605488 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: scheduling while atomic: mmcqd/46/0x00000002 (affects: 1) (heat: 132)" [High,In progress] https://launchpad.net/bugs/605488
<lag> rcn-ee: Not having much luck there are we? :)
<rsalveti> rcn-ee but nice you're working on this issue, things will be much easier to merge when we get your patches at least linux-omap upstream :-)
<rsalveti> rcn-ee: some other questions I have, related with xM
<rcn-ee> lag, getting closer. ;) one little tweak at a time.. ;)
<rsalveti> maybe lag and ogra can tell more about it
<rsalveti> I wanted to understand the known issues we got with the hardware
<rsalveti> I have a p8 board
<rsalveti> lag: what rev is your xm?
<rcn-ee> that has the bad 512Mb Micron, some work, some don't...  Production boards are using Neomonix.. well until Micron figures out why they corrupt randomly.
<rcn-ee> i have a P7, it's 256Mb Micron..
<rsalveti> rcn-ee: oh, got it, thanks for the info
 * ogra has micron too, but rev. A 
<rcn-ee> it has other issues, like crashing into a ball of fire when your run "sudo aptitude update"
<ogra> my former one was P7 as well
<ogra> but with 512M
<rsalveti> random issues doesn't seems good hehe
<ogra> i think the rev. A ones are supposed to be more stable but i might be wrong
<rcn-ee> that's weird.. according to my cheat sheet from gerald, the P8 was the first 512, but considering those are marked with a  marker. ;)
<ogra> hmm, i might misremember and it might have been an 8
 * lag has a Micron 
<rsalveti> lag: but what rev?
<rcn-ee> i think all out are micron right now.. the actuall production ones will be Nuemoinx..
<rcn-ee> let see "A" changed gpio related to mSecure, USB host1 (to a header), USB reset and Sysboot changes..
<rsalveti> rcn-ee: cool, you have the logs :-)
<rcn-ee> yeah the early one... hasn't been updated since May thou.. the current log is on the schematic of the "A2" on beagleboard.org (it doesn't have the old Px changes)
 * rcn-ee runs work back in a couple hours.
<lag> I think the USB is broken on my Panda :(
<rsalveti> lag: why?
<lag> It doesn't work
<lag> usb 1-1: new high speed USB device using musb_hdrc and address 3
<lag> usb 1-1: device descriptor read/64, error -110
<lag> usb 1-1: device descriptor read/64, error -110
<lag> usb 1-1: new high speed USB device using musb_hdrc and address 4
<lag> usb 1-1: device not accepting address 4, error -110
<lag> usb 1-1: new high speed USB device using musb_hdrc and address 5
<lag> usb 1-1: device not accepting address 5, error -110
<lag> hub 1-0:1.0: unable to enumerate USB device on port 1
<prpplague> lag: es1.0 board:?
<lag> How do I tell?
<ogra> black or not ?
<prpplague> lag: is the pcb green or black?
<ogra> es2.0 are painted black
<rsalveti> the only issue I saw regarding the usb is the dma problem
<rsalveti> musb_hdrc.use_dma=0 could help, but not sure if you're getting the same issue
<ogra> lag, given that you didnt tell us about a new board you got this week i'd say es2
<ogra> err
<ogra> es1
<rsalveti> lag: es2 has the pandaboard logo
<prpplague> because of some hardware issues related to the the TWL6030 configuration on ES1.0 boards, not all the time when the board boots with something plugged into the MUSB does it enumerate properly
<ogra> and apart from tobin the es2.0's should all still be in delivery
<prpplague> try rebooting with the MUSB unplugged and plug it in after booting
 * ogra wonders how much the pandas differ within the es1.0 line 
<ogra> i havent seen any issues regarding musb on my es1
<prpplague> ogra: it varies
<ogra> yeah, i was guessing so, like the XM
<lag> Green
<ogra> now that was a prompt answer :P
<lag> ogra: shh
<lag> ogra: I'm doing more than one thing at once
<ogra> really ?
<ogra> you can ?
<rsalveti> lol
<lag> I think you misunderstand me - it used to work
<prpplague> lag: you mutli-task?
 * ogra always secretly suspected female genes in lag
<prpplague> lag: new kernel ?
<ogra> there was a new meta today so likely a new kernel too
<lag> prpplague: Yeah
<lag> prpplague: I'll test the kernel separately - wait one
<prpplague> lag: np,
<ogra> hmm, the kernel is from the 5th though, i wonder why meta wasnt updated alongside
<rsalveti> I tested the newer kernel already, seems to be working fine
<prpplague> lag: try a simple test, just boot the boot without anything plugged into the MUSB and then plug it in after booting
<rsalveti> ogra: cooloney forgot about it
<rsalveti> when he updated the main debs
<ogra> rsalveti, ah
<ogra> would have been nice to have it in the alpha release though :P
<ogra> ah well
<ogra> cant have everything
 * ogra glares at the maverick-changes ML
<ogra> coinor-flopc++ ...
<ogra> looks like someone just hit random keys to make up a package name
 * prpplague tries to decide what to do about panda audio
<ogra> prpplague, emmet (persia) will take care of it (at least he said so yesterday)
<prpplague> ogra: ??
<prpplague> ogra: you mean about the audio?
<ogra> though i dont see him online today, seems he still has issues with his new appartment and internet
<ogra> prpplague, yep
<prpplague> ogra: ahh, right, this is more for internal TI L24.x release
<ogra> the ASoC module needs to expose the right stuff to make pulse aware of the different devices i think
<ogra> it doesnt do that atm
<prpplague> ogra: i'm trying to decide if panda should share the sdp4430 audio file, or split it off for it's own
<ogra> ah
<prpplague> ogra: yea that is being done in the L24.9 release
<ogra> main target needs to be to not need an asound.conf
<prpplague> hmm
<prpplague> ogra: the thing is that the panda doesn't have a number of the channels that the sdp has
<prpplague> ogra: none of the mic
<ogra> well, then the driver needs fixing
<ogra> asound.conf is a hack to override broken driver defaults, if the driver doesnt expose the right HW to userspace that needs fixing in the driver
<prpplague> ogra: right, so the question is, do we share the sdp4430.c file and add a bunch of "machine_is_omap4_panda()" or do i create a seperate file
<ogra> heh, your choice i guess, whats working better for upstreamability later ?
<prpplague> yea that's what i'm trying to think through now
<ogra> prpplague, you could probably ask lrg as ASoC upstream buy ;)
<ogra> s/buy/guy/
<prpplague> ogra: yea already have a ping out for him this morning
<ogra> ah
<prpplague> ogra: he's burried with the L24.9 release as well
<ogra> heh
<ogra> all of TI is it seems
 * ogra is only sitting with a bucket on his knees waiting to catch the stuff that comes downstream :)
<prpplague> hehe
<lool> what a nice metaphor
<lool> It could have been worse
<prpplague> hehe
<ogra> lool, you mean it could be a cup ?
<lool> it could be in another place than on your knees
<mopdenacker> ogra: I've tried the alpha3 installer and it works fine so far...
<ogra> great
<mopdenacker> ogra: The only bad thing is that the first boot phase is completely silent for a few minutes (while it extends the partition). I had to add "console=ttyO2,115200n8" to the bootargs to actually see something.
<mopdenacker> This could confuse users, thinking that their system is frozen. And they could reset their board and corrupt their rootfs which is currently being resized.
<ogra> well, the image is designed in a way that you dont need to use serial
<ogra> you should attach a HDMI monitor
<mopdenacker> ogra, I understand...
<ogra> how big is your SD ?
<mopdenacker> 8 GB
<ogra> the resizing shouldnt take more than a few mins (1-2) nowadays
<mopdenacker> ogra, you're right. It took approximately 2 minutes.
<lag> lag> It doesn't work
<lag> <lag> usb 1-1: new high speed USB device using musb_hdrc and address 3
<lag> <lag> usb 1-1: device descriptor read/64, error -110
<lag> <lag> usb 1-1: device descriptor read/64, error -110
<lag> <lag> usb 1-1: new high speed USB device using musb_hdrc and address 4
<lag> <lag> usb 1-1: device not accepting address 4, error -110
<lag> <lag> usb 1-1: new high speed USB device using musb_hdrc and address 5
<lag> <lag> usb 1-1: device not accepting address 5, error -110
<ogra> we fixed that right before the alpha release (i didnt remove the thxt that tells you "10min per 4G yet)
<lag> <lag> hub 1-0:1.0: unable to enumerate USB device on port 1
<ogra> *text
<mopdenacker> I did attach an hdmi display, but nothing got displayed during the first boot phase (before the reboot to the installer)
<ogra> intresting, but it did work on second boot ?
<mopdenacker> ogra: Yes, it did.
<ogra> hmm, weird
<ogra> robclark, ^^^ any idea why the first boot wouldnt work on HDMI but the second does ?
<ogra> (we dont change any graphics related boot options or anything)
<robclark> ogra: hmm.. is the first boot over too quickly before the monitor can sync?
<robclark> and is there any way you could get a bootlog w/ omapdss.debug=1?
<ogra> no, it takes a few mins
<lag> Someone's USB broken also?
<robclark> hmm.. and same kernel?
<ogra> and it does an auto-reboot so capturing the dmesg is a bit of an effort
<robclark> oh, ok..
<ogra> its the alpha3 release, works on my monitor for first and all subsequent boots
<robclark> well, I can't think of any particular reason why it would not work on first boot, but would work on subsequent boots..   but I guess I don't know enough about what changes between first boot and second boot..
<robclark> same MLO/u-boot/uImage?
<ogra> yes, all the same
<robclark> any difference which could change timing and expose a potential race condition?
<ogra> first boot is console only, second is using plymouth
<ogra> and i think GrueMaster saw some similar issues in the past
<lag> ndec: ping
<robclark> hmm.. but framebuffer should come up before you even get to userspace..
<ogra> yeah
<lag> jayabharath: ping
<jayabharath> lag: hi
<jayabharath> lag: did you try to plug in usb kybd after boot up..
<jayabharath> lag: there was a problem that sometimes usb peripharl was not detected when you have it plugged in on cold boot
<lag> jayabharath: I have
<prpplague> lag: can you send you me your kernel image, i'll test here
<prpplague> lag: and info on what kernel source you are using
<lag> prpplague: Email address?
<prpplague> lag: x0132446@ti.com
<jayabharath> prpplague: I remeber there was a TWL OTG VBUS issue.. was this a HW fix or kernel change
<prpplague> jayabharath: kernel fix
<lag> jayabharath: prpplague: I'm going to rebuild our latest kernel
<lag> prpplague: When I've done so, I'll send you the .deb
<rsalveti> ogra: thanks for targeting the bugs for beta
<rsalveti> easier to track now
<ogra> rsalveti, well, i have to else i'll get grilled in the release meeting :)
<rsalveti> oh, true :-)
<mopdenacker> ogra: I got disconnected from the Internet, sorry. I may have missed replies from you.
<ogra> mopdenacker, i didnt reply any further to you, i just know that someone in here (i think GrueMaster) had a similar prob before
<GrueMaster> Sorry, what was the issue?
<mopdenacker> ogra: All right... we can continue to investigate. Thanks!
<ogra> GrueMaster, black screen on first boot on the panda but working monitor after the first reboot
<mopdenacker> GrueMaster: having no graphical output with the preinstalled images....
<ogra> (after resizing)
<GrueMaster> I was seeing that too yesterday, even with my additional parameters I have had to set.  Not even seeing serial console output.
<mopdenacker> Though in both cases, I had to add hdmi driver bootargs to get the display to work.
<mopdenacker> Right, console serial output wouldn't hurt, even if a serial console is not a requirement.
<GrueMaster> My panda first boot cmdline:
<GrueMaster> setenv bootargs vram=32M mem=463M   root=/dev/mmcblk0p2 fixrtc console=ttyO2,115200 console=tty0 omapdss.debug=1 omapdss.hdmimode=0 omapdss.hdmicode=35
<ogra> it breaks the splash screen
<mopdenacker> ogra: Ah, right.
<mopdenacker> GrueMaster: Got the same bootargs as you do (without console=tty0, which is a good idea btw, and without omapdss.debug)
<mopdenacker> ogra: Are you supposed to detect the monitor type, and then load the display drivers from the initramfs with the corresponding settings?
<ogra> mopdenacker, the kernel is supposed to detect the EDID from the monitor and set the right stuff
<ogra> (inside the driver)
<ogra> and its kind of a myth why it does that right on second boot but not on first
<mopdenacker> ogra: I understand, thanks.
<mopdenacker> I can investigate  this within TI, reproduce it in a simple testcase and file a bug report. Thanks again!
<ogra> mopdenacker, robclark has worked out patches that we dont have on the images yet
<ogra> *could* be related
<ogra> though its still a myth why it works on second boot
<mopdenacker> ogra: I will try with our own images too. Thanks!
<prpplague> mopdenacker: what problem are you seeing?
<mopdenacker> prpplague: no graphical output on the first boot phase (with pre-installed images), and then a correct display after rebooting. Same kernel, same bootargs (except a root= setting with UUID).
<prpplague> mopdenacker: which platform? panda?
<ogra> prpplague, panda with the ubuntu image
<prpplague> ahh ok
<prpplague> and is it a HDMI or DVI display?
<mopdenacker> ogra: I had to hardcode the hdmi settings in the bootargs in both cases. So, the question in my case (and in GrueMaster's) is why we don't get anything on the display during the first boot phase.
<mopdenacker> prpplague: with HDMI
<ogra> i dont think our kernel supports the DVI port yet at all
<prpplague> ogra: it does, but only barely
<prpplague> mopdenacker: do it is a hdmi display connected to the HDMI port?
<prpplague> because GrueMaster 's boot args are for a DVI display
<mopdenacker> prpplague: no, it's a DVI-D display.
<GrueMaster> For the record, I am using the hdmi port with an hdmi<>dvi cable to a dvi monitor.
<prpplague> right
<mopdenacker> Same here. I was told by ndec that the DVI port didn't work yet.
<prpplague> running DVI-D via the HDMI doesn't read the EDID, which is why the args have to be passed
<rsalveti> I believe it's reading the edid with latest robclark's patches
<mopdenacker> prpplague: Ah, right!
<rsalveti> or at least something
<lag> prpplague: I've send the email
<lag> prpplague: 14MB of .deb coming your way :)
<prpplague> lag: dandy, i'll have a look between L24.9 testing
<lag> prpplague: np
<prpplague> rsalveti: i'll check with robclark
<robclark> prpplague: if you use HDMI->DVI adapter, then you get EDID..  there were some issues with DVI specific parts of the EDID not being parsed, but most of that is implemented now with latest patches
<lag> prpplague: I have to go now - ping me an email when you have some news
<prpplague> robclark: ahh ok, so L24.9 should have the patches included?
<rsalveti> prpplague: http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commits/L24.8_panda-hdmi-patches
<rsalveti> I tried to test but got -vsync with my monitor
<robclark> prpplague: not all of them..  in particular, the ones about EDID parsing aren't yet ;-)
<prpplague> robclark: ahh ok, i'll see about getting that in panda branches
<prpplague> mopdenacker: i'll merge those edid patches in about an hour
<mopdenacker> prpplague: awesome, thanks!
<mopdenacker> prpplague: on dev.opamzoom.org?
<mopdenacker> s/opamzoom/omapzoom
<mopdenacker> prpplague: should be able to test next Tuesday. Thanks!
<rsalveti> mopdenacker: I have a kernel deb file with these patches at http://rsalveti.net/pub/ubuntu/kernel/maverick/
<rsalveti> get 903.7 rsalveti2
<rsalveti> if you want to test now
<mopdenacker> rsalveti: thanks! Too late for today, really gotta go...
<rsalveti> np :)
<lag> prpplague: Are you still there?
<lag> prpplague: Here is the image:
<lag> http://people.canonical.com/~ljones/usb-stopped-panda/
<lag> prpplague: Email didn't work
<prpplague> lag: pulling now
 * rsalveti needs coffee
<ndec> lag: still around?
<prpplague> ndec: hey, the panda board hdmi fixes have not been pull from display-next as of yet
<ndec> prpplague: hi
<prpplague> ndec: btw, this is Dave Anders
<ndec> prpplague: so this is normal if it does not boot?
<ndec> prpplague: i know you who are ;-)
<prpplague> ndec: sorry just wanted to make sure
<prpplague> ndec: yea
<ndec> prpplague: which patch do I need to pull? i'd like to make a quick test before my vacations ;-)
<prpplague> ndec: one sec
<prpplague> http://dev.omapzoom.org/?p=axelcx/kernel-display.git;a=commit;h=ff6125dde94754d36dcb12dbb4e1d8e35726bcbd
<prpplague> ndec: plus you need to set the vram to atleast 16
<ndec> prpplague: just this?
<prpplague> ndec: that should be all that is require to make it bootable
<prpplague> ndec: you may have to turn off power management in the config, there is one patch (not panda specific) that needs to be pulled
<ndec> prpplague: ok. have you enabled usb host?
<prpplague> ndec: yea, the EHCI and MUSB have been tested
<prpplague> ndec: i'll retest everything this afternoon
<prpplague> ndec: the audio patches have been submitted and should be pulled soon as well
<ndec> prpplague: thanks. it booted once... no display, no ethernet... i will try this again after my break... good luck;-)
<prpplague> ndec: i'll keep testing
<prpplague> ndec: np, there are still some things to be pulled from the other trees
<ndec> prpplague: ok. thx
<Martyn> Arm L2 cache -- generally write-back, or write-through?
<rsavoye> if anybody is also building icedtea, please try this patch. I'm also doing more testing of it
<rsavoye> http://www.senecass.com/projects/OpenJDK-ARM/thumb2-081310.patch
<lool> rsavoye: I met Tom Marble at Debconf, he was interested in your work
<rsavoye> yeah, I'm donating some old HPPA HW to Tom for OpenJDK testing
<rsavoye> lool: it's been interesting getting my head back into assembler programming
<rsavoye> plus Ed doesn't need comments in his asm code :-)
#ubuntu-arm 2010-08-14
<vanhoof> anyone around who can help an arm n00b? :)
<vanhoof> a friend gave me a babbageboard to play w/ (unknown state), not sure on exact model, but looks identical to this: http://ossguy.com/?p=317
<vanhoof> using these instructions: https://wiki.ubuntu.com/ARM/BabbageKarmicInstall
<vanhoof> problem is, I plug it in, it's getting power, but nothing is displayed through VGA/DVI
<vanhoof> monitor never detects a signal, nic port on switch never lights up ... I'm assuming its off, and needs to be powered on, but theres nothing i'm seeing labeled as a power button, unless i've had one too many beers.  The push button (in the bottom of the pic) yields nothing (labeled sw9)
<rsalveti> vanhoof: you could try newer versions
<rsalveti> like lucid or maverick (still on development)
<vanhoof> rsalveti: just tried the lucid build
<rsalveti> I'd recommend you lucid first
<vanhoof> same result
<rsalveti> vanhoof: do you get at least an yellow screen during boot?
<rsalveti> this is the boot loader writing some output so you can see that it works with your monitor
<vanhoof> rsalveti: i get nothing at all, as if its not powered on
<vanhoof> black screen, power saving mode, no activity on the nic on the switch
<rsalveti> oh, it's a babbage, not beagle :-)
<rsalveti> DVI port output does not work / is unstable: Display output on Babbage 2.x boards is underpowered and relatively unstable. The board might not be able to display any image with some DVI screens. This issue is particularly visible on Babbage 2.0 boards. Freescale recommends various hardware modifications to workaround the issue. This hardware issue is not tracked in Launchpad.
<rsalveti> from the https://wiki.ubuntu.com/ARM/KarmicReleaseNotes
 * vanhoof will give vga a go again
<rsalveti> it'd try to follow basically what is described at the wiki page first
<rsalveti> https://wiki.ubuntu.com/ARM/BabbageImageFromScratch
<rsalveti> can also help debugging
<rsalveti> but I know nothing about this board :-(
<vanhoof> thanks for the help
<vanhoof> same result w/ vga
<vanhoof> it really looks like its getting power properly
<vanhoof> but needs to be 'turned on'
<vanhoof> theres just nothing obvious labeled as a power button, and the one button that is, does nothing
<vanhoof> and of course i cannot find this model on freescale's site :D
<rsalveti> vanhoof: there are people here that have and test this board, like NCommander, GrueMaster and dyfet, but they are probably not on-line now
<vanhoof> rsalveti: cool
 * vanhoof just figured it'd be something fun to play around w/ this weekend
<vanhoof> im sure im likely doing something dumb :D
<rsalveti> :-)
<rsalveti> vanhoof: maybe updating the bootloader and kernel could help
<vanhoof> rsalveti: you'd still expect to see some activity once powered in, right? eg nic lights on switch, screen should come out of power saving mode?
<vanhoof> or is the entire bootstrap process controlled within the image i put on the sd card?
<rsalveti> vanhoof: dpm
<rsalveti> argh
<rsalveti> don't know if this board has nand or any other memory to boot from at the first stage
<rsalveti> if it loads the bootloader from the sd card, then you'll probably need a sd card with the correct image on it
<rsalveti> then it'd be important if you could track the uart output
<rsalveti> to see what's happening
<vanhoof> yah, got nothing to see whats going on :D
<artz> hi all
<artz> I am not using ubuntu arm but I guess it would be fine to ask a question about arm-linux in general, right?
<kblin> depends? ask?
<artz> ok
<artz> I am trying gprof on arm
<artz> and I am getting all nan's as time
<artz> even though the call tree seems fine
<artz> and time granularity is reported to be 'nan' too
<ogra_cmpc> moo
<ogra_cmpc> asac, 2.5h isnt bad i'd say :D
<kblin> artz: never tried that
<asac_> ogra_cmpc: yep. very good ;)
<kblin> rcn-ee: say, do you have a BB kernel that supports the ceph cluster fs?
<rcn-ee> kblin, probally.. is it not enabled?
<kblin> haven't checked yet, actually
<kblin> so far I was planning on using a hawkboard for my demo
<rcn-ee> just about everything is enabled.. it might be an external module thou
<kblin> but I'm still waiting for the hardware
<kblin> I'll check that
<rcn-ee> nope.. CONFIG_CEPH_FS is not set (2.6-stable)
<rcn-ee> not in 2.6.35-devel either..
<kblin> ok, I guess it's about time I figure out how to build my own kernels then :)
<kblin> I still hope "embedded private cloud storage" is less stupid than it sounds
<kblin> but imagine you had a bunch of nas drives you could connect to your network, and automatically your virtual central storage server would have more disk space
<kblin> while all you need is a bunch of hdd enclosures spread around the house wherever there's a free power socket..
<rcn-ee> something like http://pastebin.com/rwg9zvJ5 on top of my 2.6.35-devel script should do the job..
<kblin> oh, btw, you don't really want to build smbfs anymore
<kblin> cifs is better in every aspect, smbfs has been deprecated years ago
<kblin> rcn-ee: thanks for the pointers
<kblin> SIGBED
<rcn-ee> i can drop that.. ;)  it may have occured when i sync'd with ubuntu's config..
<rcn-ee> i just use ext/btrfs/nfs so anything else doesn't get tested. ;)
 * NCommander waves to ogra and rcn-ee 
 * rcn-ee NCommander your beer's empty.. ;)
<NCommander> rcn-ee: I haven't had any beer yet
<NCommander> Language barrier :-/
<rcn-ee> what's up NCommander
<NCommander> rcn-ee: just saying hi, since I'm not usually awake at this hour
<rcn-ee> gotcha, what time is it there, i keep forgeting your time zone..
<NCommander> rcn-ee: +8
<NCommander> or +12
 * NCommander checks
<NCommander> no, I was right the first time
#ubuntu-arm 2011-08-08
<siji> Hi All
<siji> Anyone can help me to configure touch screen in ubuntu natty
<siji> I have insmod the driver
<siji> ads7846
<siji> what are the parameters need to be add in xorg.conf ?
<ogra_> siji, see #ubuntu-touch (or so it is called i think)
<siji> ogra,thanks
<siji> ogra_, they redirected me to #ubuntu-arm  :)
<ogra_> lol
<ogra_> what does that have to do with arm ?
<siji> because am doing it in beagleboard
<siji> BeagleBoard XM
<siji> ads7846 -->TSC2046 (TI's Touch Screen Controller)
<siji> ogra_, I think the driver module which am hving is wrong
<siji> cose evtest also not responding with any input key events
<ogra_> and ? why would it matter if its on a beagleboard or on a HP server machine ?
<ogra_> :)
<siji> That's true ;)
<ogra_> (or ... weird thought ... on a tablet device :P )
<siji> :)
 * TheSeven wonders if https://bugs.launchpad.net/linux-linaro/+bug/709245 lost attention again
<ubot2> Ubuntu bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed]
<ogra_> no
<ogra_> many people watch it i doubt it *can* lose attention
<stgraber> NCommander: bug 787749 (marked Invalid but not sure why and no clue of what's the current state)
<ubot2> Launchpad bug 787749 in linux-ti-omap4 "Missing configuration for LXC containers on omap4" [Undecided,Fix committed] https://launchpad.net/bugs/787749
<ogra_> stgraber, isnt user ns deprecated ?
<ogra_> in 3.0 that is
<stgraber> ogra_: my understanding is that actual user namespace hasn't been implemented yet (it's on the todolist for this week lxc sprint in Austin)
<stgraber> but might be a case of same name for different things :)
<ogra_> i think i saw a kernel message pass by last time i compiled a kernel
 * ogra_ has to run out, back in 30min
<pcpower> where can I find the gpio pin configurations for the pandaboard on the stock ubuntu 10.10 image ?
<NekoXP>  /sys/class/gpio ?
<pcpower> apparently it's specified in the x-loader source
<pcpower> ...somewhere
<NekoXP> http://pandaboard.org/sites/default/files/board_reference/A1/750-2152-002-sch_revd.pdf it'd be easier to read them off the schematic
<NekoXP> unless you want the actual configuration like hysteresis settings and drive strength for the pads
#ubuntu-arm 2011-08-09
<pcpower> NekoXP: I want to use pins for GPIO inside of ubuntu
<pcpower> it seems like I have to recompile x-loader and change some header or something, in order to do that
<pcpower> and I just have no idea where to start
<NekoXP> not sure why you'd be required to change x-loader?
<pcpower> all I want is a couple gpio pins on the physical board I can set high and low
<pcpower> NekoXP: I think because it's defaulted that the pins are setup as GPMC/i2c and other things
<pcpower> and not GPIO
<pcpower> the pins are all 2 or 3-purpose
<NekoXP> you should be able to do that in the kernel
<NekoXP> it's the wrong place but you can do it
<NekoXP> I've not done any omap4 stuff but there should be some kind of pinmux stuff around you can kick.. isn't there a pin header on the board anyway?
<NekoXP> my panda's at the office...
<prpplague> NekoXP: yes the proper place is the kernel, however pcpower has no experience doing any dev work, he just needs to know where one gpio is already configured
<prpplague> NekoXP: gpio 139 and 140 are already configured
<NekoXP> schematic :D
<NekoXP> I disagree that pinmuxing should be done so late, but :_
<NekoXP> if you need to just hack around it's much quicker in the kernel
<prpplague> NekoXP: schematic doesn't tell you what the software is configured for
<NekoXP> yeah but if you want to change it who cares what it's already configured for
<NekoXP> you just need to find some pins which are on the board but not connected to some other device
<NekoXP> hopefully with no pullups or pulldowns or weird stuff
<prpplague> NekoXP: thats the whol point, he doesn't want to compile anything, he just wants to know that is already configured
<prpplague> NekoXP: i already gave it to him anyway
<NekoXP> so I answered him already :) /sys/class/gpio has a list of pins configured as gpio and cross referencing would have found which ones were free and where on the board they are
<prpplague> NekoXP: no that is no correct
<NekoXP> really? is panda that much different to any other board using gpiolib?
<prpplague> NekoXP: if the gpio hasn't been exported, it will not show up in /sys/class/gpio
<NekoXP> hmm yeah I guess you have to request it first
<NekoXP> but if 139 and 140 are already configured that's implied
<prpplague> NekoXP: only the pinmux is configured, doesn't mean it has been requested
<NekoXP> okay so he needs to kick around in the kernel anyway
<NekoXP> ?
<prpplague> NekoXP: no, he just needs to export the gpio
<prpplague> GrueMaster: ping
<prpplague> GrueMaster: where the heck is the x-loader source for maverick omap4 support?
<GrueMaster> Couldn't tell you off hand.  I'd have to load a system with maverick and then look at a package.
<GrueMaster> let me see if I can find it by other means
<prpplague> https://launchpad.net/ubuntu/maverick/+source/x-loader-omap4
<prpplague> GrueMaster: nm, found it
<GrueMaster> I was looking for the git tree.
<GrueMaster> But that works.
<prpplague> GrueMaster: getting killed with people wanting to do i2c and gpio from 10.10 lately
<electroglue> hello can anyone tell me why ubuntu-omap4-extras-multimedia package fails in ubuntu...I see that two packages have been updated and wont be installed because they no longer exist in the ppa
<siji> Good  After noon friends
<siji> need  some help to enable my beagleboard XM with touch screen
<siji> it's TSC 2046 Controller
<siji> and I have "insmod" ads7846.ko (2.6.38-8)
<siji> but evtest is not responding for touch events
<siji> any help pls
<siji> persia, u there?
<siji> ogra_, you there
<siji> [  956.874450] ads7846: disagrees about version of symbol module_layout
<siji> means wrong driver module right ?
<ogra_> yes
<ogra_> how did you build it ?
<siji> am wondering how it's happen, i have build the OS image from rootstock
<ogra_> i mean how did you build that module
<siji> ogra_, it was there bydefault
<siji> in the rootstock build image
<ogra_> cant be :)
<siji> yes, it is
<siji> :)
<ogra_> there is no kernel in rootstock images by default
<siji> linux-omap
<ogra_> so that cant be
<ogra_> unless you forcefully added one
<siji> i hve added the parameter linux-omap
<ogra_> ??
<ogra_> the message above means that your module was compiled differently from the rest of the kernel ... that simply cant happen in a packaged kernel
<siji> right..
<siji> i did seed linux omap
<ogra_> so check what kernel packages you have installed
<siji> while building rootstock
<siji> ok
<siji> ogra_, i have build the rootstock with the parameter --seed linux-omap
<ogra_> did you check your installation ?
<siji> yes
<siji> it seems like everything is fine
<siji> running on kernel 3.6.38-8 omap
<ogra_> locate ads7846
<ogra_> where is that located
<siji> /lib/modules/kernel/---
<ogra_> where exactly
<ogra_> i dont see it being built in any of our arm kernels
<ogra_> ogra@panda:~$ locate ads7846
<ogra_> ogra@panda:~$
<siji> /lib/modules/2.6.38-8-omap/kernel/drivers/input/touchscreen
<ogra_> definitely not enabled on omap4
<ogra_> very strange
<ogra_> oh, i see, on omap4 it is compiled in
<siji> oh..
<siji> but mine is omap3
<siji> beagleXm
<ogra_> right, i dont have one running here so i cant check
<siji> ok
<ogra_> file a kernel bug then against the linux package (mention omap3 in the description)
<siji> ok
<ogra_> though that still doesnt explain the error
<ogra_> and i think only the kernel or touch teams could help here
<siji> ok
<siji> or I have to build the kernel here right?
<ogra_> you could do that too, indeed, or try one of rcnee's kernels (there is a PPA somewhere with his kernel packages)
<siji> i have tried but failed to enable SGX driver
<siji> anyway will give a try again
<ogra_> make sure to file bugs if you find issues ;)
<siji> sure will do
<hrw> nvflash looks fun
<ogra_> heh
<hrw> nightmare kind of fun
<ogra_> what for do you need it ?
<hrw> ogra_: Hannspree hannspad - cheap android 10.1" tablet
<ogra_> ah
<ogra_> well, if you have a good kernel you should only have to use nvflash once
<ogra_> i.e. a good kernel like the ac100 one wheer you can see the boot partitions from userspace :)
<hrw> problem is that there are no good kernels for it. vendor 'forgot' to give gpl source so kernels from community only and they lack few things
<ogra_> did someone report it as gpl violation already ?
<hrw> checking that is on my todolist
<ogra_> well, generally the chromeos kernels are a good start for tegra stuff
<cjwatson> Hi, I can't figure out why https://launchpadlibrarian.net/76889732/buildlog_ubuntu-oneiric-armel.libvirt_0.9.2-4ubuntu8_FAILEDTOBUILD.txt.gz is failing; I don't *think* it's due to my change.  Would somebody be able to have a look.
<cjwatson> ?
<ogra_> me looks with no promises that he has more clue
<ogra_> wow, looks really bad
<infinity> cjwatson: Is that a python testsuite?
<infinity> cjwatson: If so, I imagine it relates to https://launchpadlibrarian.net/76841318/buildlog_ubuntu-oneiric-armel.python-apt_0.8.0ubuntu3_FAILEDTOBUILD.txt.gz
<ogra_> well, doesnt look like anything used libnl3 on arm before
<cjwatson> infinity: not seeing the link ...
<cjwatson> (but I don't actually know, I'm entirely new to libvirt and was just trying to get everything shifted over to libnl3)
<ogra_> cjwatson, wild guess: the missing classid file gets pulled by a netlink socket, our kernel on the ancient buildd HW misses bits the nl3 lib uses, so the dtd doesnt end up where it should be
<ogra_> (really wild guess)
<infinity> Oh, I didn't look closely.  I'm barely awake here. :P
<infinity> Brain just saw two testsuites die. :P
<ogra_> i dont have a panda with a disk atm, but i can do a testbuild on an ac100
<ogra_> to see if its machine related
<rOxx> Hello, i want to test the uart port on the beagleboard xm with a oszilloscope to check the uboot configuration, i have disabled kernel pinmux. i know that uart2 is ttyO1, are there any possibily to send data over this port ?
<fisuk> does anyone have any idea why i get inverted colors on my cursor and the xterm text, like this: http://dl.dropbox.com/u/952540/wtf.jpg
<fisuk> if i swap to a text console and back to X, then they show up correctly
<fisuk> also, there's no text showing up on any of the apps
<fisuk> some underscores here and there, but mainly nothing is visible
<ogra_> what arch is that ?
<fisuk> omap4, custom maverick rootfs, kernel 2.5.35-980-omap4
<fisuk> i have no idea what I've messed up because an earlier rootfs i built didn't have that problem..
<fisuk> well, i guess i'll just rebuild the thing for the millionth time.
<fisuk> before that it'd be nice if i could even once get the video decoding hw accelerated, but there's no info about that on the wiki. or anywhere. i mean, there's the installation instructions for omap4-extras and "use totem", but no information about what videosink should be used when using gst-launch etc. or if any other pads are required.
<ogra_> it should just work out of the box in maverick
<fisuk> oh
<ogra_> there are no codecs provided by TI for natty so dont bother to try it there (or bug TI)
<ogra_> we should get codecs for oneiric again
<ogra_> cjwatson, fyi, thats how the libvirt build fails for me in a oneiric chroot on an ac100 http://paste.ubuntu.com/662055/
<ogra_> fails a lot earlier in test-chown
<janimo`> ogra_, openmax codecs from TI?(re your chat with fisuk above)
<ericb2> FYI, testing Nathy on Pandaboard, I got I/O errors with a brand new SD card ( Lexar, Class 10, 32GB).  I can resize the partition, and at reboot -> nothing. After some investigations, I isolated this issue : http://paste.lisp.org/display/123918
<ericb2> all the other cards I tested work as expected. The second 32GB I tested, has other problems : I got lot of I/O issues at runtime (e.g. compiling a big application), and the fs is remounted in read only mode
<ericb2> after some little search, the relevant code in the kernel is located in drivers/mmc/card/block.c
<ericb2> at least the error messages (say the what, not the why)
<ericb2> anybody aware of 1) existing issues ?  2) existing bug reports around that ?
<ericb2> thanks in advance for any help
<ericb2> :-)
<infinity> You might just have bad cards.  I have no issues here with an LX 32G Class 10.
<MrCurious_> ericb2: you any further in finding the cause?
<ericb2> infinity: thanks for the info
<ericb2> infinity: could this be another issue type, like the resize does something wrong, or I don't know ?
<ericb2> infinity: the problem is, I  got other issues with the same disk image
<ericb2> infinity: like file system suddenly in read only mode, every time the machine has a good load or something similar
<MrCurious_> ericb2: i tried with a manually resized image, that was good. its not resize thats causing the problem
<ericb2> MrCurious_: thanks
<MrCurious_> np
<ericb2> MrCurious_: you avoided me to try myself :)
 * ericb2 scratching his head 
<ericb2> MrCurious_: so we are two with problematic cards, both class 10 and high speed (at least this is written on the package)
<ericb2> other possibility could be a wrong high speed card, e.g. identified with high speed parameters and that's not true, causing timeout and worse
<TheSeven> davidm: so it's now official that the scheduler is the culprit?
<davidm> TheSeven, it's official it's a general ARM issue, not a Panda USB issue
<davidm> likely scheduler but not completely sure about that
<davidm> Was best rename I could come up with that fit what we are seeing
<davidm> ope to suggestions for a better name
<TheSeven> it would be interesting if this is only related to USB, I/O in general, or even every kind of thread execution
<infinity> TheSeven: It's not just USB, and probably not just I/O.  It really looks like it's spinlocking breakage.  I'm assured that people smarter than me are looking deeper.
<davidm> IT also makes a difference on writing to the SD card
<MrCurious_> my guess is it has hard coded timings that just work with slow cards, rather than detecting card state, allowing for it to run at max speed
<MrCurious_> or a hard coded wait that isnt needed with faster cards
<davidm> infinity, I'm trying to get as many people as possible looking at it ;-P
<MrCurious_> if i had to "guess"
<infinity> MrCurious_: I use a few class 10 cards (one even the same brand as ericb2) with no issues.
<TheSeven> davidm: but compared with what's going on with USB storage, the differences on the SD interface were almost neglegible
<TheSeven> s/with/to/
<MrCurious_> rev c board?
<infinity> TheSeven: Yes, but SD is slower by default, so sitting in idle loops 75% of the time doesn't hurt as much. :P
<ericb2> infinity: I believe you. Just searching how I can proof my reseler it is defective / not good
<MrCurious_> at least my board was rev c
<ericb2> infinity: this card is expensive (76 euros), and I'm not happy
<TheSeven> ericb2: SD cards just aren't intended for compiling things on them
<ericb2> TheSeven: he he
<ericb2> TheSeven: I'm testing the armhf build on USB stick
<ericb2> TheSeven: on USB disk, it works. Trying the usb key now (more easy for traveling)
<MrCurious_> ericb2: usb is currently buggy, and possibly 10x slower than it should be
<ericb2> MrCurious_: promising ^^
<ericb2> MrCurious_: I was wondering whether an sata support will arrive some day
<ericb2> would be fantastic
<ericb2> sata is reliable, really
<GrueMaster> Doubtful on panda.  Maybe omap5?
<ericb2> GrueMaster: indeed, it will probably not occur with Panda . Crossing the fingers
<ericb2> for omap5 .. in one, two years ?
 * ericb2 hides 
<infinity> Find me a mobile phone that needs SATA...
<GrueMaster> Other than adding it to the USB bus, I wouldn't get your hopes up on panda.
<infinity> (Panda's essentially a phone dev platform)
<ericb2> infinity: I meant more a multimedia one ( double hdmi .. )
<GrueMaster> Panda is the same hardware as the Droid 3.
<ericb2> + lot of decoders inside. Looks lke a mix of best technos, for hackers and like
<GrueMaster> Other than a few NAS systems out there, I don't know of any mainstream arm based products that also have sata.
<infinity> There are tons.
<infinity> Mostly set-top boxes, PVRs and the like.
<GrueMaster> Mainstream?
<infinity> Well, depends on how you define "mainstream".
<TheSeven> MrCurious_, ericb2: USB is still way faster than SD
<ericb2> maybe nfs, as I told previously
<GrueMaster> Most of those are PPC based afaik.
<infinity> Most people get them bundled with cable service and such, but that's pretty "mainstram", you just don't go comparison shopping.
 * GrueMaster owned a tivo and owns an HD DVR.
 * ericb2 got a powerbook in the room. bought in october 2005 or so
<ericb2> works well
<TheSeven> davidm: So it doesn't make sense to do further random testing and throwing results at the bug from my side?
 * davidm still owns 2 working tivo series I and has 4 for spare parts
<ericb2> oops, it's late, and I need to sleep a bit
<davidm> Any valid testing might help, the bug is not isolated as yet
<ericb2> good night all
<infinity> Apparently the PVR in my house is MIPS.
<davidm> OK I'm off, I'll look at the back scroll later
<ericb2> infinity: got a gdium too :)
 * ericb2 gone for true
<MrCurious_> theseven: i use a ssd on usb, it makes ubuntu on panda tolerable :D
<GrueMaster> MrCurious_: Try booting with nosmp and checking your IO performance.
<TheSeven> MrCurious_: a thumbdrive would do as well
<MrCurious_> yeah
<MrCurious_> gruemaster: is that a opt for boot.scr?
<GrueMaster> Yes.  Add to the kernel cmdline.
<MrCurious_> is that going to kick the speed up?
<MrCurious_> but at a cost
<GrueMaster> IO speed should be 3-4x but no SMP.
<MrCurious_> thats a strange tradeoff
<MrCurious_> counterintuitive
<infinity> See above about spinlocks.
<MrCurious_> doubt spinlocks are broken, more like not optimized
#ubuntu-arm 2011-08-10
<zul> has anyone tried running libvirt on oneiric on the arm?
<ogra_> zul, did it build yet ?
<ogra_> yesterday it failed
<ogra_> i tried a local build but that failed even earlier
<zul> ogra_: im using an older version i think 0.9.2-4ubuntu7
<ogra_> right, with yesterdays upload it FTBFS
<zul> ogra_: really? grrr
<robclark> ogra_, hey, is there any minimal (ie. less than 200mb headless) image for natty?
 * robclark looking for link for recovering busybox user
<ogra_> sure wiki.ubuntu.com/ARM/OMAP
<robclark> thx
<robclark> ogra_, but headless img is still quite large (by busybox standards)..
<robclark> I thought there was something smaller..
<ogra_> there is ubuntu-core in oneiric, thats just 35M
<ogra_> the natty ones are around 200M
<robclark> ok.. then I guess oneiric it is
<ogra_> note though, ubuntu-core is just a rootfs
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/releases/oneiric/alpha-3/
<ogra_> and give feedback to infinity, its his baby :)
<robclark> that is fine.. it is for a kernel developer
<ogra_> well, there is no user creation or system configuration at all, you need to do all of it manually
<robclark> I think that is fine for someone coming from busybox ;-)
<ogra_> k
<ogra_> :)
<robclark> hmm, don't see the ubuntu-core img..  and looks like alpha-2 is gone..
<ogra_> just use the link above
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/releases/oneiric/alpha-3/
<ogra_> its not an image, its a tarball
<robclark> yeah, yeah..  but either I'm blind or there still isn't anything smaller..
<robclark> hmm, ok..
 * ogra_ sees 35M next to the tarball file
<robclark> hmm..  I search for "tar" and don't even find any match on the page
<robclark> ahh, wait, wrong url
<ogra_> using the same link ?
<ogra_> aha
<robclark> nm, my bad
<amitk> robclark: have you tried the linaro nano images?
<robclark> hmm, no
<robclark> amitk, linaro nano images, one can still 'sudo apt-get install'?
<amitk> robclark: yes
<amitk> robclark: they are stripped down headless
<amitk> robclark: https://wiki.linaro.org/Cycles/1108/Release#Developers_and_Community_Builds
<robclark> ok, cool..
<amitk> ogra_: it would be interesting to know the ubuntu-core and nano and combine them
<amitk> ogra_: *know the difference between
<LPhas> hello, i've a question. i don't really need gdm and gnome on my pandaboard, so i would like to be able to run startx as a user on boot, instead of getting gdm start. how can i do that?
<ndec> ogra_: hey. what's the ubuntu core image exactly?
<siji> LPhas, yes you can
<ogra_> ndec, it is not an image, it is close to what you would get by using debootstrap to create a chroot
<ogra_> just a tarred up chroot without any setup or configuration
<ndec> how is it built?
<ogra_> using live-build like all other images
<ndec> which packages are installed? ubuntu-minimal?
<ogra_> less i think, aks infinity or look at the manifest files of the daily
<infinity> ndec: More or less debootstrap --minbase ... Which is a LOT less than ubuntu-minimal.
<infinity> ndec: And I suspect I'll strip it down further at some point.
<ndec> ok. what's the purpose of this image, well tarball
<ndec> and what's the uncompressed size on SD?
<infinity> It's for people to build their own random systems around.  Tiny rootfses as a starting point is a pretty common use case in the (pseudo-)embedded space.
<infinity> Honestly, it's something I except most people to ignore. ;)
<ogra_> yeah
<infinity> But it can be handy at times (I installed my ac100 with it).
<ogra_> way to much effort to actually make it proper
<infinity> Uncompressed size right now is 110M or so?  I think?
<ogra_> wow, that big ?
<infinity> ogra_: Well, making it "work" it just a kernel, a bootloader, and setting up /etc/{hosts,resolv.conf}
<infinity> But making it useful is a bit more effort for most. :P
<ogra_> creating a user, making sure tz and locale are correct etc
 * infinity nods.
<ogra_> loopback networking too ...
<ogra_> etc
 * ogra_ always forgets half of it unless he has to implement it somewhere
<LPhas> siji, thank you... how?
<ndec> i am one of these guys that make custom derived ubuntu images , hence my interest ;-)
<ogra_> ndec, well, better use the server image as a base or so
<infinity> ogra_: Oh, and it's about 96M now, not 110.  Apparently.
<ndec> i am just wanted to make sure i know what it is.. for now, i have been quite happy with the regular desktop images. as i told you in the past we 'chroot' them to install our packages so that it becomes a custom pre installed image. and it's been enough for now
<ogra_> yeah, i think i remember 80 from some years ago using minbase ...
<infinity> And the "which image to use" question depends on what you intend to do with it.  If you want it to have an installer, core's probably not for you.
<ogra_> i guess if we dropped all the drm libs it will be around that again
<infinity> core is for people who start from scratch, build a "perfect" gold image of exactly what they want, and then burn it to each device on its way out the door.
<infinity> That sort of use case.
<infinity> Like I said, pretty common in the (semi-)embedded space, pretty rare in the rest of the world these days.
 * ogra_ builds the first ac100 rootfs 
<ogra_> lets see if infinity's tarball handling in live-buildd works :)
<ogra_> *live-build
<infinity> Define "works".  It's pretty sketchy. ;)
<amitk> infinity: are you talking to the linaro team where they are doing nano images?
<infinity> amitk: Oddly enough, "nano" images never came up during the week I was actually in the same room with them.
<amitk> infinity: that is why irc is so much better ;)
<ogra_> infinity, well, i just run "ARCHES=armel+ac100 buildlive ubuntu daily-preinstalled" on antimony ... if a vmlinuz, rootfs and initrd come out at the rearend i call that "works" :)
<infinity> ogra_: That doesn't sound like it would produce a tarball.
<ogra_> infinity, why not? for ac100 the filesystem is defined as plain
<ogra_> it should just dtrt if i didnt misunderstand the code
<infinity> Well, assuming buildlive has any concept of any of that.
<ogra_> and it didnt fail yet
<ogra_> i added it to buildlive, yes
<infinity> It might just work, then.  I'll be pleasantly surprised. :)
<ogra_> (if a build survives 30min it usually finishes ... i'm 20min in)
<infinity> Oh, it'll finish on the buildd side, no issues.  I'm more curious about what happens after that.
<ogra_> nothing yet
<ogra_> i only call buildlive atm, debian-cd doesnt have any post processing code yet
<infinity> But I guess I did hook support for plain into find/download-live-filesystem and such, so it should probably DTRT.
<ogra_> i sould only find a tarball, initrd and kernel in the right dir under /srv/cdimage ...
<ogra_> if it doesnt i'll fix it (thats why i'm doing this testbuild atm)
<infinity> Heh.
<ogra_> the live-build documentation is nearly unusable imho
<infinity> There's documentation?
<ogra_> man live-build or live-build -h doesnt get you any info
<infinity> (Yeah, it's awful)
<LPhas> please any idea on how to execute startx as a user on boot?
<ogra_> only the sub-script manpages will
<infinity> LPhas: You mean manually?
<LPhas> no
<ogra_> use a display manager and configure autologin ...
<LPhas> automatically
<cipher> is there a way, given a node in /dev, to lookup more information about that device?
<LPhas> ogra_, why should i use a display manager? O_O
<ogra_> because you want x to function properly :)
<cipher> i.e. some function F('/dev/foo') that gives info such as: that's a usb device, or that's a tty
<infinity> Because DMs do autologin already.
<LPhas> basically i want to do what with the old good init i do with
<LPhas> x:5:once:/bin/su - -- PREFERRED_USER -l -c '/usr/bin/startx </dev/null >/dev/null 2>&1'
<ogra_> and also care for setting up the envioronment
<ogra_> LPhas, so just do the same with upstart then
<LPhas> i can't understand upstart
<LPhas> i don't know bash
<siji> LPhas, if you are using ubuntu
<infinity> LPhas: /etc/init/tty*.conf ... Change one to do what you want instead of spawn getty.
<siji> you can do autologin by adding exec /sbin/mingetty --autologin exnxt tty1 --Only for Console AutoLogin
<LPhas> infinity, let's try
<siji> "exnxt-->username"
<LPhas> siji, this look to be console autologin
<ogra_> LPhas, just use what you used before for startx
<ogra_> exec bin/su - -- PREFERRED_USER -l -c '/usr/bin/startx
<ogra_> err
<ogra_> exec /bin/su - -- PREFERRED_USER -l -c '/usr/bin/startx
<ogra_> that should just work
<ogra_> though i dont think infinity is right, you cant use the tty.conf scripts, they start on the wrong event so you might miss bots in the system
<ogra_> s/bots/bits/
<infinity> ogra_: gdm starts before tty* in our usual setup, it should be fine.
<infinity> ogra_: (Try it sometime, boot your laptop and when GDM comes up, hit the consoles, getty's still not running)
<ogra_> start on (filesystem
<ogra_>           and started dbus
<ogra_>           and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
<ogra_>                or stopped udevtrigger))
<ogra_> stop on runlevel [016]
<ogra_> emits starting-dm
<ogra_> you will likely need all that
<ogra_> especially the emits
<ogra_> since other scripts look for it
<siji> ogra_, you mean modifying tty*.conf is not the right method
<ogra_> i mean that tty.conf likely has the wrong events
<siji> ok
<siji> here am doing some experiments on the same
<infinity> None of the DM or session events should matter if your goal is to have a single X.
<siji> Trying to run XBMC in autostart
<ogra_> well, the above snippet is actually from a display manager .conf file
<infinity> If you have other services listening for those events, they'll fail regardless. :P
<infinity> ogra_: Yes, I know, but "startx" isn't a DM.
<infinity> ogra_: And it doesn't actually provide session or dm services.
 * infinity shrugs.
<ogra_> thats why you need the "started dbus" event
<infinity> Only if you use dbus.
<ogra_> might be that you have a started dbus anyway by reacing runlevel2
<infinity> (He was saying he was going GNOME-free and the whole nine yards)
<ogra_> which nearly all desktops do today
<ogra_> oh, ok
<ogra_> if there is no desktop, dbus might not matter
<infinity> Still, as I said, our current tty stuff (that just runs on [23]) starts well after our DMs do, so...
<infinity> It's probably fine. :)
<ogra_> but if you use any app that needs a session bus you are screwed
<siji> ogra_, it seems like my prblm is also same
<siji> i have made autologin by modifying tty1.conf
<siji> then in my DM (xfce) created a *.desktop file for autostart XBMC
<siji> and XBMC starts working but, while I pressed any keys in keyboard the application is hanging
<infinity> ogra_: You lose.
<infinity> The following packages have unmet dependencies: ubuntuone-client-gnome : Depends: ubuntuone-client (= 1.7.0-0ubuntu2) but 1.7.1-0ubuntu1 is to be installed unity : Depends: unity-common (= 4.6.0-0ubuntu2) but 4.6.0-0ubuntu4 is to be installed
<siji> but mouse is working fine
<ogra_> infinity, i dont ! i have a logfile now !!! :)
<infinity> ogra_: Heh.
<ogra_> BAH !!!
 * ogra_ curses the archive being totally out of sync
<ogra_> no way to build test images with that ... grmbl
<ogra_> ubuntu-one ... and unity are both broken
<ogra_> sigh
<infinity> They both build quickly enough.
<infinity> Or are they FTBFS?
 * infinity looks.
<ogra_> i dont think they are
<ogra_> unity was just uploaded today ... arch all should already be ready ... any is missing as usual
<infinity> unity is. :/
<ogra_> sigh
<ogra_> so no way for me to make FF with ac100
<infinity> Oh, because of libnux skew.
<infinity> FFS.
<ogra_> yeah, as usual
<infinity> On armel and PPC.
<ogra_> not sure whats up with ubuntuone
<infinity> And boost...
<ogra_> it already caused failed images last night
<ogra_> is there a way to build server without preinstalled pool ?
 * ogra_ ponders to move on with server images to get around that ... but i dont want to waste time on a 300MB pool 
<infinity> Not without editing auto/config currently.
<ogra_> hmm, k
<infinity> Not sure that's a feature I care to add, since the only time you'd want that is when testing locally...
<infinity> And for local testing, you can edit the config. :P
<ogra_> oh, i actually wonder ...
<ogra_> ---what happens if i use ubuntu-core as a flavour
<ogra_> would i still get a kernel/initrd with the tarball ?
 * ogra_ tries for laughs
<ogra_> lets see if i kill antimony with that :P
<infinity> You really won't.
<infinity> Get kernels, I mean.
<infinity> Actually... You might.
<ogra_> why ? depends if the subarch code overrides your plain code
<infinity> Since core defines the no kernel business before the subarches happen.
<ogra_> yeah
<ogra_> i was hoping so
<ogra_> what does -core end up with for root ?
<ogra_> locked or just no passwd ?
<infinity> No password.
<infinity> I think.
<ogra_> like debian then ?
<infinity> To be fair, I'm not positive.
<ogra_> because i think that is modified in ubuntu
<infinity> Actually, it's probably just locked out of the box.
<ogra_> so if you dont override that default it will be locked
<infinity> I dunno, I use it as a chroot, what's a password? :)
<ogra_> heh
<infinity> (And it's meaningless as an installation image too, since part of installation is creating a user and/or setting a password)
<infinity> So, yeah.  Probably locked, but never checked.
<infinity> I wonder what "--linux-packages=none --linux-flavours=ac100" will do to live-build's tiny brain.
<infinity> Cause that's what you're going to end up with.
<ogra_> am i ?
<infinity> Should do.
<infinity> Plus explcitely installing the packages anyway.
<infinity> So.
<infinity> The tarball will be right.
<infinity> I'm just curious how it will handle those two options.
<infinity> We'll find out.
<ogra_> well, the subarch code uses add_package
<infinity> For science!
<infinity> Yeah, subarch uses add_package, which gets the files on disk.  But then later, you get --linux-flavours=$FLAVOUR if $FLAVOUR is set.
<infinity> For core, that's normally none, but it got set to SUBARCH.
<infinity> But core also set --linux-packages to none to work around some other misfeature.
<infinity> And I'm too lazy to trace and see what happens when those two conflict. :)
 * ogra_ wants livecd.sh back !
<infinity> Yeah, me too.
<ogra_> silly complex crap
<infinity> I can't help but feel like we've mostly reimplemented livecd-rootfs in auto/{config,build}, and we're just using live-build as a super complex debootstrap wrapper. :/
<infinity> But whatever.
<ogra_> thats what we do, yeah
<infinity> Maybe we'll move more and more into the core functionality and work around fewer and fewer misfeatures over time and learn to love it.
<ogra_> i think that was colins initial plan
<infinity> His plan was to learn to love it? :)
<ogra_> lol
<ogra_> no, to move livecd-rootfs into live-build over time
<LPhas> are there any enviroment differences between lauching a program with Alt-F2 (run program) and starting a gnome-terminal and launching from it?
<ogra_> bug 823971
<ubot2> Launchpad bug 823971 in ac100 "Enhancement: Suggestion to use jffs2 Filesystem" [Wishlist,New] https://launchpad.net/bugs/823971
<infinity> ogra_: Oh, the ubuntuone-client-gnome thing isn't arm arcive skew.
<infinity> ogra_: The ubuntuone kids just completely removed client-gnome. :P
<infinity> ogra_: So, time for some seed updates.
<infinity> s/arcive/archive/
<infinity> Or...
<infinity>     - Removed ubuntuone-client-gnome deps and binary packaging, as it was
<infinity>       moved out to separate project upstream.
<infinity> Maybe not time for seed updates, maybe time to go hunting through the NEW queue...
 * infinity hunts.
<ogra_> why the heck dont theys notify anyone ?
<ogra_> sigh
<infinity> And I see no new sources...
<infinity> So, we just have broken image builds.
<infinity> Yay.
<ogra_> you shoudl put yourself in the notification list on cdimage :P
<ogra_> sycamore.buildd finished at Wed Aug 10 14:42:05 UTC 2011 (failed)
<ogra_> *sniff*
<ogra_> (that was core)
<ogra_> hmm, i dont get the prompt back
<ogra_> infinity, heh, so it finishesd and i see it installing abootimg, linux-ac100 and friends ... but it fails with "ls: cannot access vmlinu?-*: no such file or directory"
<ogra_> so i guess it wipes /boot somewhere
<ogra_> hmm
 * ogra_ wonders if running find on /srv/cdimage.ubuntu.com/scratch/ was a bad idea ... runs since 10min now
<ogra_> hmm
<ogra_> i dont really see where it removes vmlinuz
<ogra_> ah
<ogra_> got it
<ogra_> hmm
<ogra_> so --linux-flavours=none doesnt seem to be set, else it wouldnt move to the ls that fails
<ogra_> oh
<ogra_> KVERS="$( (cd "binary/$INITFS"; ls vmlinu?-*) | sed -n "s/^vmlinu.-\\([^-]*-[^-]*-$FLAVOUR\\)$/\\1/p" )"
<ogra_> do i misread that line or does it actually expect /vmlinuz-$vers-$flavour instead of /boot/vmlinuz-....
<infinity> ogra_: No, cause INITFS should be boot.
<ogra_> oh, ok
<infinity> Oh, depending on what LB_INITRAMFS is set to...
<infinity> Which I'm not sure about for core, since it has none, so I probably didn't follow that codepath.
<ogra_> ah, that might not be set correctly given i do something weird :)
<infinity> What, with core not actually requiring a kernel at all.
<ogra_> well, i see it being generated in the log
<ogra_> so /boot should have vmlinuz and initrd files
<ogra_> it just seems like lb doesnt know about that :)
<infinity> Right, but INITFS is set based on LB_INITRAMFS and lord knows what that's set to.
<ogra_> heh
<ogra_> well, its sad to see it getting that far and then fail
<ogra_> its really in its very last stages there
<infinity> Oh, wait, no.
<infinity> *scratch head*
<infinity> INITFS is boot for core, that's fine.
<infinity> But...
<infinity> That's not the boot you think it is.
<ogra_> well, indeed i want the boot where linux-image unpacked vmlinuz to :)
 * infinity tries to sort out where these kenrels get copied around...
<infinity> I suspect it's just live-build not copying kernels out because of the linux-*=whatever confusion.
<infinity> So, ultimately... Don't use core for this. :P
<ogra_> yeah
<infinity> Or test locally with a hacked-up auto/config
<ogra_> but we dont have headless either anymore
<ogra_> hmm, or do we
 * ogra_ looks 
<infinity> We don't.
<infinity> But testing this on the buildds seems silly anyway.
<infinity> You get much better turnaround testing locally on x86, then doing one final local test on arm.
<infinity> Well, assuming you have a reasonably close or local mirror..
<ogra_> i need to know the structure of the dump the buildd gets me to move on
<ogra_> thats all i'm after atm
<ogra_> and thats why i do it on the buildd, i surely wont run a local debian-cd to do debian-cd development for the post-boot scripts
<infinity> In theory, it should look the same as a mix of core and live.
<infinity> That is, the rootfs will look like cores output, but the kernels should look the same as what live's doing.
<ogra_> i dont need core, i just tried it because desktop is blocking me atm
 * infinity nods.
<ogra_> i will do server, that just takes longer
<ogra_> but should get me building images and accurate output files
 * infinity spots a thinko in his auto/build ...
<infinity> Or, rather, a place where I have a (correct) hardcoded value that should probably be a variable, to match everything else.
<infinity> But harmless.
 * ogra_ fires off an ac100 server build
<ogra_> EEEKK !!!!!!!!!
<infinity> That's not a good sound.
<ogra_> building ubuntu-server gets me a germinat traceback in the log !!!!
<infinity> I had considered making redirecting the germinate call, but I figure it might be handy for debugging some day.
<infinity> s/making //
<ogra_> well, you need to proceed the seed somehow to get the ship seed, no ?
<infinity> The logs aren't meant to be pretty anyway. :P
<infinity> Well, yes.  We need to run germinate.
<ogra_> i dont care about the logs, my build dies after about 10sec with germinate failing
<infinity> Err, really?
<ogra_> giving me a key error
<ogra_> 'usb-langsupport'
<infinity> Local, or on a buildd?
<ogra_> take a look at sycamores logs
<ogra_> ubuntu-server-ac100
<infinity> Curious.  Last night's server-omap4 ran fine.
<ogra_> yeah
<ogra_> seeds might have changed today
<infinity> A local germinate run is just as broken, though.
<infinity> So, someone just broke the seeds, I guess.
<ogra_> key error smells like it
<infinity> Or.  What?
 * infinity blinks.
<ndec> ogra_: i think i asked you already... but i forgot ;-) when using unity2D which WM is used? metacity?
<ogra_> yep
<ndec> thx
<infinity> Something on lillypilly just went very pear-shaped.
<ogra_> you broke it !
<ndec> davidm: hi there. any news on the global availability of ARM PPA
<infinity> Or I can't type.
<infinity> There, that's better.
<infinity> Yes, broken seeds.
<davidm> ndec, none yet, IS is working on intergrating the first builder
<ogra_> yep
<ogra_> alison broke them
<infinity> ogra_: Yeah, I see the commit that's broken, but it's not immediately obvious to me what broke it. :P
<infinity> ogra_: You found the issue?
<ogra_> nope, i pinged colin, i dont really know about all the inheritance stuff
<ogra_> it seems ot be a completely new seed
<GrueMaster> ogra_: Do we still need the mem= lines on panda?  I haven't seen any issues lately, and the netinstall doesn't add them.
<infinity> It is.
<ogra_> GrueMaster, we need them for ducati (multimedia)
<ogra_> so we still need them on the desktop
<ogra_> server, not so much
<GrueMaster> Ah.
<ogra_> ducati requires a memory hole at the right place iirc (we should check if thats still at the right position nowadays though)
<ndec> so you don't want to use the server image for transcoding video?
<ogra_> if people use it like that they should adjust boot.script :)
<infinity> If there's a piece of hardware on this that requires the memory hole, we should have it there regardless of installation type...
<ndec> we should update boot.script in the ducati package as postinst and force a flash-kernel and reboot ;-)
<infinity> (We should probably just have the kernel doing it by default)
<ndec> infinity: it's a s/w limitation, not h/w
<infinity> ndec: How so?
<ndec> we reserve come carve out memory for a special h/w accelerator, the physical address reserved in hard coded in the kernel...
<infinity> None of that sounds like a software limitation to me...
<ndec> well, the h/w does not require the memory hole. it's our s/w design that requires it
<infinity> As in, we could be talking to it directly somehow, instead of mmapping it in system RAm?
<infinity> I would have assumed this is just how it's designed to be done.
<infinity> Either way, my point was that if the hardware's there, and if that addressing technique is our only way to talk to it, we should just have the hole on by default and be done with it.
<ndec> i would tend to agree... the counter argument is that you are wasting 50Mb of RAM for the server image, and that might be important too...
 * infinity shrugs.
<infinity> omap4 isn't a serious server platform anyway.  Losing 50MB to make sure all the hardware is doing the right thing from userspace's POV feels right to me.
<infinity> And, as you point out, omap4 as a media server is probably a more likely use-case than as an HPC cluster.
<infinity> Just a guess. ;)
<ndec> i personally don't care too much (now) about the omap4 server image anyways ;-)
<infinity> Well, it's just a proof-of-concept anyway.
<infinity> But I could see repurposing my Panda as a set-top-box once I get "real" ARM server kit in here for other server testing.
<ndec> and guess what if you had installed the server image *without* the memory hole in bootargs, and convert it as set-top-box then video won't work because the hole is for the video accelerator!
<ogra_> pfft, details
<infinity> But yes, I still think the boot args are a silly, messy, and error-prone waste of space.  If the kernel knows where that hole should be, we should just have the kernel set it up by default.
<infinity> And people could use a mem= line to override and undo that if they really know what they're doing and care deeply about the 50MB.
<infinity> rsalveti: Thought on the above?
 * rsalveti reading
<GrueMaster> I like that idea.  We are limited to the amount of characters on the kernel cmdline, removing the two mem= lines helps considerably.
<GrueMaster> (my cmdline length issue is PXE boot netinstall w/ preseed mainly).
<ogra_> yeah
<ndec> can we setup the memory map from the kernel?
<rsalveti> ogra_: infinity: we've being using with the 50MB hole at natty even without any working multimedia modules ;-)
<rsalveti> for me it feels ok to just remove it and use the whole 1gb for a server image
<rsalveti> if someone would like to setup the ti ppa, it'll probably need to do it by hand anyway
<ogra_> rsalveti, well, the discussion was about moving the option as a default into the kernel instead of having a cmdline option for it
<rsalveti> so we just document the changes at the boot.args and be ok with it
<rsalveti> this feels wrong
<rsalveti> as it's a software limitation
<ogra_> you should be able to override the default with your own mem settings indeed
<rsalveti> but having the hole as a default option seems wrong for me
<rsalveti> default should be everything
<rsalveti> as it's the user choice to use ducati and so on
<rsalveti> as it's not free software
<ogra_> but we would default to make the device non functional
<ogra_> imho all HW on the board should work by default
<rsalveti> ogra_: but this is a sw limitation :-) and to enable it you have to use closed source components
<rsalveti> that's why enabling it by default seems wrong for me
<ogra_> well, the closed source components wont work if it isnt set
<rsalveti> are we having the closed source components for oneiric?
<ogra_> we will
<rsalveti> we didn't have for natty, and all images have the useless 50mb hole
<ogra_> likely post release but its planned
<rsalveti> problem is that we can't change the bootargs easily
<rsalveti> otherwise this wouldn't be a problem
<rsalveti> once the user installed the extra packages
<rsalveti> but for a normal user, wanting to use the server image or just using it with free software, making him lose 50mb for nothing seems wrong :-)
<infinity> It's just 50MB.
<infinity> I'd rather lose 50MB that no one will even notice or care about than have people complain that something doesn't work right.
<infinity> And server on this hardware is a proof-of-concept, not a finely-tuned machine. :P
<infinity> Oh my, feature freeze is here already.  How time flies when you miss the beginning of a cycle.
<martyn> hey, where can I find a listing of the Canonical sprints?
<martyn> I just found out there was one going on here in Austin
<martyn> (yesterday(
<GrueMaster> martyn: They are on an internal wiki and only by invitation to outside members of the community.  Sorry.
<martyn> Ahhh .. okay, I thought they would be up on Fridge
<martyn> thanks
<GrueMaster> They are mainly for us to get face time with our coworkers.  Most companies that work out of offices don't have the collaboration issues that working from home does (nor do they have some of the freedoms - like sitting in on a meeting in your pajamas).
<GrueMaster> They're great for cross-team pollination of ideas/solutions.
<martyn> Yep, and in the case of the Austin sprint .. a great way to get exposed to some heat.. (
<martyn> it's 107F today :)
#ubuntu-arm 2011-08-11
<ogra_> E: config/chroot_local-hooks/preinstall-pool.sh failed (exit non-zero). You should check for errors.
<ogra_> infinity, ^^^ where do i find that ? searching for that script in either livecd-rootfs or live-build doesnt reveal anything
<ogra_> oh, got it, ignore me
 * ogra_ didnt expect a here doc
<ogra_> hmm, i dont see why it failed and it doesnt spitinto the log
<ogra_> s/spitinto/spit out anything into/
<ogra_> cm'on publisher, spit out an ubuntu-meta for me
 * ogra_ twiddles thumbs
<siji> hi all
<siji> am facing some prblm (may cose of less expertise) while trying to build kernel module
<siji> I have downloaded the kernel source from rep. by apt-get install linux-source
<siji> extracted and tried to build only touch screen module
<siji> by the command make modules SUBDIRS=drivers/input/touchscreen/
<siji> But it built only three modules, even more dirver files are there
<siji> Where am wrong ?
 * ogra_ suggests to ask in #ubuntu-kernel
<siji> ogra_, ok
<siji> Hope they wont redirect me here again :)
<ogra_> heh, i doubt it
<siji> ;)
<ogra_> dou did configure it before, right ?
<siji> yes
<siji> ogra_, btw, i was not aware of that ubuntu is having this much IRC channels
<ogra_> every team has one usually
<ogra_> and then there is #ubuntu-devel,#ubuntu and #ubuntu-meeting
<siji> oh..
<siji> ya, it's very easy to get help , isntead of messing up everything in a single channel
<siji> *instead
<ogra_> we started out with #ubuntu-devel only ... but as the developer community grew it got to niosy
<siji> ok
<siji> so you people are having seperate team for each  ?
<ogra_> there is a desktop team, a kernel team etc etc
<siji> ok, so there might be a ubuntu-arm team too (assumes you are became part of it )
<ogra_> right
<siji> cool ..
<siji> ogra_, this is for you
<siji> <apw> siji, if you have ARM specific questions you may get quicker answers on #ubuntu-arm, the peeps who mostly have the h/w hang out there
<siji> :)
<siji> :)
<N3o> hello! Is there a problem with the repositories ? I get many Hash Sum mismatch after doing an apt-get update on a PandaBoard with natty
<N3o> this is my sources.list file and the errors I get: http://pastebin.com/NAEteeXh
<rsalveti> janimo: libvirt bug 823711
<ubot2> Launchpad bug 823711 in libvirt "libvirt version 0.9.2-4ubuntu8 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/823711
<GrueMaster> N3o: There has been some issues with the pool for the last few days.  This may be some of the fallout.  Work is being done to clean it up.
<ogra_> rsalveti, yeahm, thats a weird one
 * ogra_ comments
<janimo> rsalveti, yes, I'll look at that
<infinity> GrueMaster: Erm, there's been nothing that would cause hash sum mismatches.  Just archive skew.
<ogra_> infinity, well, look at the cdimage buildlogs for today xubuntu builds
<ogra_> they expose the same
<infinity> N3o: The usual suspect for hash sum mismatch issues is either a slightly broken mirror, or having a proxy (often a transparent one) between you and the archive.
<infinity> ogra_: Yes, but this is natty he's using.
<rsalveti> GrueMaster: janimo: u-boot SPL is basically a replacement for x-loader
<ogra_> its the third time today i hear someone mentioning hash sum mistmatches with the archive
<rsalveti> u-boot will now generate u-boot.bin and MLO
<rsalveti> code reuse now, only one source package and the SPL can probably boot the kernel directly :-)
<rsalveti> and once we add the usb support at SPL, it'll behave like omap4boot
<GrueMaster> rsalveti: COOL!!!
<rsalveti> we'll see how it goes for our 11.08 release, if it goes well we can do a FFe for ubuntu
<ogra_> rsalveti, any reason to not go with the binary header for u-boo.bin instaed and get rid of MLO completely ?
<rsalveti> well, you can think of MLO as a minimal u-boot now
<rsalveti> being able to boot the kernel directly is like having u-boot
<rsalveti> but without the fancy stuff, like cmdline and such
<ogra_> right, but we still need two files
<janimo> rsalveti, worth mentioning what SPL is (or link) in the spec whiteboard :)
<rsalveti> janimo: sure, will add
<rsalveti> http://www.omappedia.org/wiki/U-boot_Upstreaming_Project
<N3o> Thanks GrueMaster && infinity -- I don't have any kind of proxy so it has to be those issues you were talking about
<N3o> I'll try again in a few days
<janimo> rsalveti, thanks, sounds good
<GrueMaster> N3o: Actually, I just rebooted into natty, and am updating now without error.  Try rerunning apt-get update.
<N3o> roger
<N3o> same :(
<N3o> maybe I should try some cleaning?
<GrueMaster> couldn't curt.
<GrueMaster> *hurt
<N3o> tried that too
<N3o> same thing
<N3o> could you check my sources.list http://pastebin.com/NAEteeXh and confirm it is ok?
<infinity> N3o: Are you sure you're not behind a transparent proxy at your ISP?  It's a pretty common thing that many/most people aren't aware of. :/
<N3o> nope, I'm 100% positive
<N3o> I'm wondering, does apt-get goes trough IPv4 or IPv6?
<infinity> Yes.
<infinity> Whichever route is lower cost.
<infinity> Well, this is assuming ports.u.c has an AAAA, I don't recall. :P
<GrueMaster> N3o: Your sources.list is identical to mine.
<N3o> thanks GrueMaster
<N3o> disabled IPv6 and trying again
<N3o> same :(
<N3o> tried with sudo apt-get update -o Acquire::BrokenProxy=true and sudo apt-get update -o Acquire::http::No-Cache=True --- same effect
<GrueMaster> Try commenting out the failing archives from your sources.list, rerun apt-get update, then uncomment and rerun again.
<N3o> ok
<ogra_> rsalveti, wrt x-loader, i was referring to http://www.omappedia.org/wiki/E-MMC_boot#You_can_boot_omap3630_without_x-loader ... which i think works on omap4 as well
<ogra_> that would save us from using MLO at all
<GrueMaster> Should work well from emmc...oh, wait.
<ogra_> GrueMaster, emmc isnt different from mmc (SD card)
<N3o> dayum
<LeCherLich> ogra_: i have a question about getting the newest ubuntu to work on the Beagleboard xM rev A. i went to #beagle first, but av500 redirected me here
<N3o> something is wrong ...
<N3o> still can't install things
<ogra_> LeCherLich, yes, i saw that
<LeCherLich> i always get to the point where linux is uncompressed, it says "Uncompressing Linux... done, booting the kernel." and a couple of seconds later it crashes and begins all over: "Texas Instruments X-Loader" ...
<ogra_> LeCherLich, the desktop images have no serial enabled by default, if you want a verbose serial boot i'd suggest the server image ... you can indeed change boot.scr on a desktop image to dump out stuff to serial if you know what you are doing
<LeCherLich> i used the headless arm image
<LeCherLich> following the instructions at https://wiki.ubuntu.com/ARM/OMAPHeadlessInstall
<LeCherLich> do i still have to change boot.scr?
<GrueMaster> LeCherLich: Which image did you download?  Natty?
<LeCherLich> GrueMaster: yes
<GrueMaster> LeCherLich: Which img.gz did you download?  omap or omap4?
<N3o> universe + multiverse not working...
<LeCherLich> GrueMaster: omap
<GrueMaster> Are you on a linux host?  Try "wget -O - http://cdimage.ubuntu.com/releases/11.04/release/MD5SUMS|fgrep ubuntu-11.04-preinstalled-headless-armel+omap.img.gz | md5sum -c -"
<GrueMaster> Verify your image is good.
<LeCherLich> GrueMaster: the checksum is 6913.......fffc (cant copy+paste, i use a linux host, but its not this one)
<LeCherLich> seems to be good, according to the MD5SUMS file in the release folder
<GrueMaster> ok
<GrueMaster> Try reflashing the SD.  How big is the SD you are using?
<LeCherLich> 4gig.. so i should just repeat the whole process of installing (zcat ... > /dev/sdb) ?
<GrueMaster> Try the gunzip |dd method.  I have seen issues with the zcat>/dev method.
<LeCherLich> oh sorry i just looked at the history... i used the gunzip method already.
<LeCherLich> so should i try zcat now?
<GrueMaster> I have not had issues with the gunzip method, and found it to be reliable.  I have had %60 success rate with zcat.  That doesn't sound like the issue though.
<GrueMaster> You had mentioned zcat, which I have seen issues with, which is why I went down that path.
<LeCherLich> sorry my mistake
<LeCherLich> is there any way to make ubuntu more talkative, via the kernel line maybe?
<GrueMaster> You may want to try a modified boot.scr on the 1st partition of the SD.  To modify it, you will need to strip the first 72 bytes of data from boot.scr.
<GrueMaster> dd if=boot.scr of=boot.script bs=1 skip=72
<GrueMaster> Then you can edit boot.script.  Remove "quiet" from the bootargs line.
<GrueMaster> Then you can rebuild the boot.scr with "mkimage -A arm -O linux -T script -C none -d boot.script boot.scr"
<GrueMaster> Make sure there is a "console=/dev/ttyO2,115200n8" on the bootargs.
<LeCherLich> there was only console=ttyO2,115... (without /dev).. is that right?
<GrueMaster> Ah, yes.  my bad.
<LeCherLich> oh okay, thanks, now it's more talkative...
<LeCherLich> it hangs at about 9 seconds. last messages: mmcblk0: p1 p2 <newline> hub 1-2:1.0: USB hub found <newline> hub 1-2:1.0: 5 ports detected ... <crash>
<LeCherLich> pretty much right after it detected the mmc card...
<LeCherLich> could it be that there is a hardware problem with this card?
<LeCherLich> GrueMaster: anyways thank you very much, i will try to solve the problem tonight on my own, i may return later
<GrueMaster> ok, sorry I couldn't help more.  Maybe try adding "earlyprintk=/dev/ttyO2,115288n8" to your cmdline and see what that produces.
<ZiNC> Hey.
#ubuntu-arm 2011-08-12
<siji> hrw, you there
<hrw> yes
<siji> hrw, just want to clarify something which u mention ur blog
<siji> regd.cross complication of linux for ARM
<siji> Am trying to follow ur doc for building the kernel for beagle XM
<siji> (assumes it's ur blog)
<siji> http://marcin.juszkiewicz.com.pl/2010/10/19/how-to-cross-compile-arm-kernel-under-ubuntu-10-10/
<hrw> its mine
<siji> grt..
<siji> so for beagle hve to give the parameter linux-omap3 right?
<siji> instead of linaro
<hrw> would have to check which is now used
<siji> " hve tried with omap3 but giving the message "no source package found: linux-omap3"
<ogra_> bug 721531
<ubot2> Launchpad bug 721531 in gcc "[armel] gcc computes wrong address for main() at build time" [Medium,Confirmed] https://launchpad.net/bugs/721531
<dmart> ogra_: looks like this is now fixed?
<ogra_> dmart, indeed, i just wanted to know the title, people tend to give me bug numbers ;)
<dmart> ogra_: ah, cunning
<suihkulokki> what is tool that rapes the ubuntu changelogs and adds the: # For older changelog entries, run 'apt-get changelog libc6'
<ogra_> suihkulokki, i think thats in pkgbinarymangler or some similar tool
<suihkulokki> pkgbinarymangler - strips translations and alters maintainers during build
<suihkulokki> Is that going to alter me while I maintain packages :P
<doko> makes you a head shorter too
<ogra_> bug 820514
<ubot2> Launchpad bug 820514 in ubiquity "oem-config-remove-gtk not found during preinstalled desktop initialization" [High,New] https://launchpad.net/bugs/820514
<ogra_> bug 819900
<ubot2> Launchpad bug 819900 in livecd-rootfs "package pool implementation needs to update apt" [Medium,In progress] https://launchpad.net/bugs/819900
<ogra_> bug 819899
<ubot2> Launchpad bug 819899 in livecd-rootfs "package pools need to correctly parse override info to create tasks" [Medium,In progress] https://launchpad.net/bugs/819899
<ogra_> bug 806751
<ubot2> Launchpad bug 806751 in debian-installer "Boot partition on SD is too small on omap/omap4" [Undecided,Invalid] https://launchpad.net/bugs/806751
<ogra_> NCommander, why is that one invalid ?
<ogra_> bug 820621
<ubot2> Launchpad bug 820621 in flash-kernel "netinstall fails to make omap system bootable during install" [High,Confirmed] https://launchpad.net/bugs/820621
<ogra_> bug 709245
<ubot2> Launchpad bug 709245 in linux-ti-omap4 "ARM SMP scheduler performance bug" [High,Confirmed] https://launchpad.net/bugs/709245
<suihkulokki> doko: your latest eglibc upload doesn't really add m-a: same back, since debhelper.mk has a snippet to strips m-a fields on amd64
<suihkulokki> doko: something like this is needed: http://people.debian.org/~riku/eglibc-multiarch.patch
<doko> gahh
<doko> slangasek: ^^^ so I assume I should revert this one too ...
<slangasek> doko: heh, yes
<slangasek> I hadn't yet tracked down the source of the problem, but I did see that the last upload didn't fix it for me...
<doko> didn't see it on i386
<doko> janimo, yes, I know about the gcc build failure ;p
<dmart> plars: are you guys still discussing beagle xM USB issues, or something else?
<plars> dmart: err.. see other channel (sorry, responded on the wrong one :)
<dmart> plars: no, you were right -- I saked the question on the wrong channel ;)
<dmart> s/saked/asked
<janimo> doko, I don't doubt it, but I thought it is a practice  to file bugs on most ARM FTBFS lately . Even though I forgot to tag it as such :)
<Sjekkie> hi
<Sjekkie> I was wondering... Since Ubuntu apparently supports OMAP4, would it be possible to install Ubuntu on an Archos Gen9 Tablet once they come out? It's supposed to get an OMAP 4460 CPU, and Archos is usually quite Ubuntu friendly (one of their first tablets ran Ubuntu very well, according to a friend of mine, but that was before the iPad-era afaik)
<Sjekkie> My first thought would be that ubuntu might not support the multitouch screen in the tablet
<Sjekkie> but the SoC itself should work, right?
<plasmasolutions> Hi guys, I'm running ubuntu on my beagleboard and got a problem...when I'm running the PVR demos in the raw version (not the X11 version) I alway get a PVRShell:Unable to create surface...where should I look to find the problem?
<plasmasolutions> The X11 version are running well
<plasmasolutions> Any ideas?
<plasmasolutions> I can provide all information that you'll probably request...got the bb up and running
<infinity> Sjekkie: In theory, it should work in some way or other, but I'll reserve any definition of "work" until I see the hardware. :)
<Sjekkie> It would be really cool to have a nice Android&Ubuntu dual boot tablet
<Sjekkie> Now just wait for the Windows 8 ARM version
<Sjekkie> j/k though
<Sjekkie> That'll probably flop anyways like WinNT/PowerPC did :P
<plasmasolutions> Sjekkie: Maybe you've got an idea for me?
<infinity> Depends on how they position Win8, I suppose.
<Sjekkie> plasmasolutions: I usually seem smarter than I really am, sorry ;)
<plasmasolutions> Sjekkie: :D
<Sjekkie> Well there's gonna have to be software
<Sjekkie> that's were NT/PPC went wrong
<Sjekkie> and WinCE for that matter
<Sjekkie> Linux really runs a lot smoother on most non-x86 hardware than most Microsoft products
<Sjekkie> 'cept for Xenix on the Apple ][
<Sjekkie> But if Windows starts to fail, MS'll just steal&close some linux code like with Kerberos
<Sjekkie> which would ruin their product once more, as linux's strongpoint is the open source community to help along in development
<Sjekkie> anyhow, I'll just lay low for now, as I've just cought myself nearly spamming this chan :P
<plasmasolutions> :) So, back to my problem :)
<infinity> Okay, summer and I are no longer on speaking terms.  I think I just overheated my Panda.
#ubuntu-arm 2011-08-14
<miki> i have a question currently i have a dreamplug with an arm processor i'm on it now my question is when i used the gtkterm and done the configuration and sent raw file miniterm.py why did it upload all the source code for the boot of everything that would boot?
<miki> BTW don't send minicom executable i made that mistake too lol
<miki> it sent everything as a souce code during boot thought it was cool
<miki> miniterm.py was useful program
<miki> even the help that i typed in displayed the contents of in the form of a man page
<miki> anyone ever try miniterm.py in an arm processor?
<miki> like source code
<miki> hmmm just thought about i'm using debian linux 5.0 for dreamplug maybe don't work with other distro's idk
#ubuntu-arm 2012-08-06
<twb> lilstevie: quick question -- is XV supposed to work on the TF101, using the oooold oneiric armel images you built (and the android 2.6.36 kernel)?
<lilstevie> probably not :p
<twb> Good-o, because it isn't for me
<janimo> marvin24, so the 3.1 ubuntu kernel's CONFIG_PROFILING should be off?
<janimo> btw do you use for-next with defconfig? that did not boot for me on Friday
<janimo> I see you made an update since
<marvin24> janimo: it boots
<marvin24> did you concatenate the compiled device tree to it?
<marvin24> paz00_defconfig should be fine
<marvin24> for the 3.1 kernel ...
<marvin24> I tried it on my local branch (which is source identical to the package tree)
<marvin24> the strange thing is, disabling PROFILING helps with my own tree
<marvin24> but after building the package, it still doesn't work (same config of course)
<marvin24> also the binaries are different
<marvin24> and yes, I double checked that the source and config is identical
<marvin24> mmh, thing about it, the package used the hf compiler
<janimo> yes I use the hf compiler only lately, 4.6
<janimo> marvin24, concatenate DT to it? I never built DT kernel before so I did not know something extra is needed that make zImage does not do
<janimo> marvin24, what I see when googling is make zimage, cat boar.dt >>zImage;make uImage
<janimo> but that is for uboot
<janimo> or wait, the current ac100 bootloader cannot boot DT kernels?
<marvin24> janimo: it can, but the device tree needs to be added to the kernel
<marvin24> for u-boot, device tree can come from the bootloader
<marvin24> you need to do a make zImage dtbs
<marvin24> and then cat arch/arm/boot/tegra20-paz00.dtb >> arch/arm/boot/zImage
<janimo> marvin24, so you make a generic zimage and cat as many board DT files as you want it to be able to support?
<marvin24> no, only one
<marvin24> ideally, the bootloader supplied the device tree
<marvin24> but ours can't  right now
<marvin24> but this will change with uboot
<janimo> ah, so the same kernel booting does not mean an exact same blob but a same zImage + custom DTs
<marvin24> so you can directly boot the same kernel on different boards
<marvin24> yes
<janimo> ok, by same kernel initially I though one binary. This works too though
<janimo> will try it out once the build finishes
<marvin24> I think it must be similar on omap
<janimo> marvin24, also isn't nvec a generic driver for all tegra ECs?
<janimo> I see only paz00 uses nvec
<janimo> do the others use other EC implementations?
<marvin24> the ec is not inside the tegra
<marvin24> but somewhere else
<marvin24> so it is board specific
<janimo> so only the communication protocol is common?
<marvin24> there are other "first gen" board using nvec
<janimo> I just grepped the dt files for nvec
<marvin24> we (and trimslice) are the only non nvidia board supported by mainline kernel
<marvin24> so there is no wonder why we are the only user ;-)
<janimo> so other ECs do not necessarily use the same SMBus protocol as described in the nvdia docs
<marvin24> yes
<janimo> I thought  tegra somehow implied nvec
<marvin24> toshiba folio uses it for power supply readings
<marvin24> same for advent vega
<marvin24> but unfornately, they have their own implementations
<marvin24> janimo: if you feel lucky today, you can also try https://gitorious.org/uboot-ac100 with this kernel ;-)
<janimo> marvin24, nice. Do I just build it and flash it to the bootloader partition as an android bootimage?
<janimo> cloning it now
<marvin24> I use tegrarcm to load it to memory
<marvin24> I think that's the best way for now, because flashing it to emmc is a bit more complicated
<marvin24> http://nv-tegra.nvidia.com/gitweb/?p=tools/tegrarcm.git;a=summary
<marvin24> but you need the bct first ...
<marvin24> (the first 4080 byte of the bct partition #2 I think)
<janimo> marvin24, mainline boots showing two penguins qwith blue beaks and feet, then cannot find root, but impressive still :)
<marvin24> janimo: needs to boot from sd card
<ogra_> whats impressive ? the penguins ? :P
<janimo> the fact it boots :)
<marvin24> ogra_: maybe the blue feets
<janimo> marvin24, why sdcard? no mmc suport implemented?
<marvin24> janimo: there is some bug in the drm driver which causes color switch
<marvin24> janimo: no nvidia partition support
<ogra_> marvin24, well, penguins live on ice :)
<marvin24> I could add it though
<ogra_> you mean we could use mainline with just one patch added ?
<ogra_> or is there more that doesnt work
<janimo> that's what I was hoping but marvin24 said no way yet :)
<ogra_> what else is missing ? nvec ?
<marvin24> ogra_: we need the drm support (one patch) and optional partition support
<marvin24> everything else is there
<ogra_> hmm, so three then
<janimo> power management?
<marvin24> not yet
<ogra_> aha
<ogra_> k, that somewhat rules it out for now then
<marvin24> ogra_: but it is boot
<marvin24> *booting
<ogra_> (as  a default)
<marvin24> ogra_: don't you have a nvec-leds entry in sysfs?
<ogra_> i didnt look :P
<ogra_> http://ograblog.wordpress.com/2012/08/06/the-bamboo-feeder-automating-continuous-arm-image-tests/
<janimo> ogra_, too much hardware in the blogpost for my taste but still good :)
<ogra_> i should have scattered more cute panda pics all over the place i guess :)
<lilstevie> ogra_, that is damn cool
<ogra_> :)
<rsalveti> ogra_: you need to enable facebook/g+ sharing at your wordpress blog, can't share directly from your post :-)
<rsalveti> but it's shared at g+ now :-)
<ogra_> heh, thx
<ogra_> i dont have a fecaebook account and dont plan to get one
<ogra_> (do i ned one to enable the sharing) ?
<ogra_> G+ enabled now
<rsalveti> ogra_: nops
<rsalveti> ogra_: you just enable the sharing plugin at wordpress for it
<ogra_> ok
<ogra_> added too now
<FunkyPenguin> anyone know if u-boot in precise supports extload?
<ogra_> should, yep
<ogra_> i think all ubuntu versions since lucid do ...
<FunkyPenguin> thanks, i'll give it a go and see
<FunkyPenguin> i tried Linaro's 12.05 image on the snowball's emmc but that didnt seem to want to see the sdcard and boot from that
<ogra_> oh, snowball
<FunkyPenguin> just building the latest 12.07 release and will try that
<ogra_> note that ubuntu doesnt have any support for snowball beyond what linaro puts in the archive
<ogra_> so if linaros u-boot doesnt have extload for the snowball enabled, you wont have it
<ogra_> i can only speak for all u-boots for the supported ubuntu arches
<FunkyPenguin> which is omap?
<ogra_> omap, omap4, highbank and armadaxp currently
<ogra_> and tegra2 ac100 netbooks but there is no u-boot
<ogra_> (android based netbook which uses a fastboot based loader)
<ogra_> we used to have mx5 images too until precise
<janimo> ogra in the initial ac100 tarball, where are the hooks that create the new initramfs for the installer reboot?
<ogra_> you mean ac100-tarball-installer ?
<ogra_> there are no specific initrd hooks, it just runs a chrooted flash-kernel and puts a default initrd in place
<ogra_> (it sets MODULES=dep and diverts plymouth and cryptsetup hooks though)
<ogra_> (before doing that)
<zma> I've got a silly question. I'm trying to build kernel I fetched from git://github.com/RobertCNelson/stable-kernel.git , build_kernel script fails in the beginning to complain there is no directory "KERNEL". Am I missing something?
<zma> ahh, sorry that, I think it's for mainline kernel source
#ubuntu-arm 2012-08-07
<LetoThe2nd> 'morning!
<LetoThe2nd> whats the current recommended way fo cross-building packages, especially kernel?
<LetoThe2nd> is xdeb still alive?
<scientes> LetoThe2nd, xdeb is dead
<scientes> LetoThe2nd, https://wiki.ubuntu.com/MultiarchCross
<scientes> LetoThe2nd, also this http://gsoc.sitedethib.com/posts/apt-get_install_gcc-4.7-arm-linux-gnueabihf/
<scientes> LetoThe2nd, oh if you just want to cross-build the kernel that is easy with upstream or just from a git  using make deb-pkg
<scientes> just set the cross-compiler prefix, and run config, and make with ARCH=arm
<scientes> and install gcc-arm-linux-gnueabi[hf]
<scientes> which is in ubuntu an emdebian
<scientes> *and
<LetoThe2nd> scientes: does make-kpkg shonour the ARCH envirnoment variable?
<scientes> make deb-pkg
<scientes> please use that
<scientes> LetoThe2nd, you will know if you arch variable isn't set right, cause you will get alot of configuration questions that dont apply to arm
<scientes> (if you have set up your .config right in the first place)
<LetoThe2nd> scientes: ok, will check that out. thanks!
<scientes> the ubuntu kernel packages have configs in them to start you out if you need that
<scientes> but really you need something for your board
<LetoThe2nd> i've got a known good kernel config i'm using for rt tests :) for a start compiling on the panda was fine, but it starts to get boring ;)
<scientes> yeah you just set the cross compiler prefix variable
<scientes> and you can even set arch in your .config
<scientes> but i just run it with ARCH=arm make uImage
<scientes> and gcc-arm-linux-gnueabihf in ubuntu or emdebian has all you need to cross-compile it
<ogra_> LetoThe2nd, http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/
<LetoThe2nd> ogra_: ah, the usual suspects strike again
<ogra_> :)
<LetoThe2nd> ogra_: but does that apply to vanilla kernels also?
<ogra_> CROSS_COMPILE=arm-linux-gnueabi- make uImage
<ogra_> :)
<LetoThe2nd> gnah.
<ogra_> oh, might be gnueabihf nowadays
<LetoThe2nd> it is.
<LetoThe2nd> i mean, isn't there a compact way to cross-build vanilla kernels into a deb?
<ogra_> ah, i think they ship a way upstream but never used it
<ogra_> if its really vaniall mainline you wan, there is a kernel team PPA that has daily builds iirc
<ogra_> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<LetoThe2nd> ogra_: hard to use if you want to apply rt patches and spidev enablement...
<ogra_> that should be mainline just with the ubuntu packaging bits added
<ogra_> ah, k
<ogra_> CROSS_COMPILE=arm-linux-gnueabihf- make deb-pkg
<ogra_> try that one
<ogra_> i think thats the makefile target upstream ships for debs
<LetoThe2nd> yes, ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make deb-pkg
<LetoThe2nd> probably.
<LetoThe2nd> will let you know once i've copied everything over.
<ogra_> it wont be "proper" but at least it uses the package system
<LetoThe2nd> will lack "properness" in terms of?
<LetoThe2nd> so far i've just used make-kpkg on the target itself
<ogra_> dunno, but there must be a reason our kernel team takes the effort to do our own packaging ;)
<LetoThe2nd> possibly yes.
 * ogra_ shakes his head about amazon spam ... 
<LetoThe2nd> ogra_: pretty amazons?
<ogra_> based on my recent buyings they offer me "blah" ...
<ogra_> i just bought "blah" why would i be intrested to buy that again  ?
<ogra_> probably from a different manufacturer than i just bought it from ... butu still, where is the logic in that
<_Lucretia_> to build opengl, is there a deb with the headers in?
<ogra_> opengl ... on arm ?!?
<_Lucretia_> well, gles
<ogra_> there are mesa headers for it, yes
<_Lucretia_> there are mesa packages
<_Lucretia_> right, so just install that?
<ogra_> yes
<_Lucretia_> it won't overwrite any gl acceleration libs - not that i can find them
<alf__> _Lucretia_: What platform are you using?
<_Lucretia_> pandaboard es
<_Lucretia_> using armhf
<_Lucretia_> have installed the sgx drivers
<alf__> _Lucretia_: libgles2-omap4-sgx-dev (I don't remember the exact name) has the headers files you need
<_Lucretia_> no such package
<_Lucretia_> is it another repo i have to activate?
<ogra_> alf__, why wouldnt mesa work ? thats what we use for package builds afaik
<alf__> ogra_: I think that installing the mesa -dev packages would uninstall sgx
<_Lucretia_> that's what I was thinking - also, it would be sw rendering
<_Lucretia_> I need hw
<ogra_> oh, that could be (no idea about the deps here, i didnt look) the resulting binaries should work just fine built against mesa though
<ogra_> else everything we build packaged for gles wouldnt work ;)
<alf__> ogra_: Sure, they would work fine, but the development cycle would be horrendous (I 've been there ;)
<_Lucretia_> alf__: I don't have that package in apt - where do I get it?
<alf__> _Lucretia_: Let me check...
<_Lucretia_> thanks
 * _Lucretia_ doesn't have universe active in the repo
<alf__> _Lucretia_: do you have pvr-omap4-dev?
<_Lucretia_> yup
<_Lucretia_> in there?
<_Lucretia_> oh they're hidden away
<ogra_> https://launchpad.net/ubuntu/precise/+source/pvr-omap4/1.7.10.0.1.21-0ubuntu1 ...
<_Lucretia_> thanks
<ogra_> but if you used the PPA you should rather get the -dev package from there
<ogra_> i doubt the version matches whats in the ubuntu archive
<ogra_> (the above is whats in the archive in "restricted")
<_Lucretia_> aye
<_Lucretia_> i know
<_Lucretia_> thanks
<_Lucretia_> trying to build an app, seems to want the GL stuff as well
<_Lucretia_> ok they can be installed side by side
<alf__> _Lucretia_: btw, the correct name is libgles2-sgx-omap4-dev, can you install that?
<_Lucretia_> alf__: no
<_Lucretia_> not in my apt
<alf__> ogra_: Do you know where ^^ is? Universe maybe?
<_Lucretia_> i can turn on universe
<ogra_> alf__, see the LP page ;) its in restricted
<ogra_> (which is enabled by default ... as well as universe and multiverse usually)
<alf__> ogra_: but pvr-omap4 source doesn't seem to produce libgles2-sgx-omap4*
<ogra_> pvr-omap4-dev_1.7.10.0.1.21-0ubuntu1_armhf.deb
<ogra_> might be that rsalveti named it differently ?
<_Lucretia_> this is my sources http://pastebin.com/0b41Xi6T
<alf__> I think that pvr-omap4* just contain the files, and libgles2/gles1/egl-sgx-* enable these using alternatives (or something like that)
<ogra_> _Lucretia_, looks fine
<ogra_> alf__, well, if that package is really needed we should get it in if it isnt ... but i think we should wait for rsalveti to explain
<alf__> ogra_: agreed
<_Lucretia_> ogra_: ok
<_Lucretia_> so does the alternatives work for selecting mesa/pvr?
<alf__> _Lucretia_: Can you please run 'apt-cache madison libgles2-sgx-omap4' , so we can get a hint where the libgles2-sgx packages are.
<alf__> _Lucretia_: assuming you have libgles2-sgx-omap4 (but not -dev)
<_Lucretia_> libgles2-sgx-omap4 <- I don't have that
<alf__> _Lucretia_: ok
<_Lucretia_> I have pvr-omap4-dev
<_Lucretia_> my version of ubu is precise
<alf__> _Lucretia_: ok, so to be clear, what happens when you try to build an app that requires gles2?
<_Lucretia_> i haven't actually tried that yet
<_Lucretia_> what i have tried is something that's a bit of an abomination
<_Lucretia_> in that it still requires GL/* stuff
<_Lucretia_> its wierd
<_Lucretia_> but uses only the gles subset - it's a binding to it from Ada
<_Lucretia_> tbh, it doesn't build and i'm gonna get onto the person who wrote it
<alf__> _Lucretia_: As ogra_ mentioned before you can experiment with mesa gles1/gles2 first (e.g. on a normal desktop), and when it builds you can continue on the panda.
<_Lucretia_> ok, so it's possible to do that by using the alternatives then?
<alf__> _Lucretia_: You can install all of gl/gles1/gles2 at the same time
<alf__> _Lucretia_: no need for alternatives for that
<_Lucretia_> yes i have done
<_Lucretia_> but i have to select which version i'm using then?
 * _Lucretia_ is just a bit unsure how all this fits together
<alf__> _Lucretia_: no, there are different libraries (libGL,libGLESv2...) and header file locations. It's the app's job to select what it want to use and build using that.
<alf__> ogra_: Checking  the pvr-omap4 packages a bit more it seems they are able to work standalone. Two issues I am seeing: 1. no pkg-config files 2. They don't "Provide" libegl,libgles2 etc, I am not sure what's going on with that.
<ogra_> yeah, thus lets wait for rsalveti, i'm sure he tested them ...
<_Lucretia_> ta
 * ogra_ arghs over Bug 1032535
<ubot2> Launchpad bug 1032535 in grub2 "installArchives() failed: Setting up linux-image-3.2.0-26-generic (3.2.0-26.41) ... Running depmod. update-initramfs: deferring update (hook will be called later) Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/dkms 3.2.0-26-generic /boot/vmlinuz-3.2.0-26-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.0-26-generic /boot/vmlinuz-3.2.0-26-generic update-initra
<ogra_> wow, i'm impressed the bot can handle the description
<LetoThe2nd> ... better than being compressed by the bot
<ogra_> heh
<LetoThe2nd> my panda fails to mount a nfs share, it just gets stuck forever at the mount command. mounting the share from the desktop box works, nevertheless. any ideas where to start debugging?
<ogra_> is no_root_squash set ? (usual suspect)
<LetoThe2nd> ogra_: sure. its not for RFS anyways.
<ogra_> hmm
<LetoThe2nd> only thing a bit unusual is that the exported directory is a symplink in the end. but that used to be fine for a long time, even for RFS. and its still when i mount on the desktop
<ogra_> do you have the nfs-common stuff installed ?
<LetoThe2nd> yes.
<ogra_> stgraber, any ideas ? ^^^
 * ogra_ hasnt actually used nfs in years 
<LetoThe2nd> does nfs-mounting produce any logging somewhere?
<ogra_> syslog i would guess
<LetoThe2nd> i can start over with a backup of the fresh install, but it'll take quite some time to copy the image back.
<ogra_> nah, better debug it
<ogra_> lsmod shows nfs i suppose (and /proc/filesystems)
<LetoThe2nd> check. /proc/filesystems{nfs,nfs4,nfsd} are marked with nodev, though
<ogra_> are you using v4 actually ?
 * ogra_ isnt sure if you dont need nfs4-acl-tools then
<LetoThe2nd> not actively decided for v4
<LetoThe2nd> the exports declaration is also classically v3
<ogra_> weird
<LetoThe2nd> /srv/panda192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)
<LetoThe2nd> yeah
<LetoThe2nd> hm. IIRC i've had a lockout earlier when using another NFS mount
<LetoThe2nd> lockup
<ogra_> tried async ?
<LetoThe2nd> just done. no effect.
<ogra_> pinging the ip of the server works ?
<LetoThe2nd> yep.
<ogra_> (and i assume the spaces in your fstab line above were just eaten by the paste)
<ogra_> err /etc/exports line
<LetoThe2nd> ogra_: correct assumptions. irssi ate my tabs.
<ogra_> well, smells like a bug but without any data in dmesg or syslog its hard to nail down
<LetoThe2nd> dmesg is dead silent
<ogra_> no mount errors in syslog ?
<LetoThe2nd> also dead silent
<ogra_> very weird
<LetoThe2nd> i think i'll start over with the backupped image.
<LetoThe2nd> if it still appears then, it really is a hard bug.
<ogra_> well, we need at least some datapoints
<LetoThe2nd> hard to find.
<stgraber> LetoThe2nd: is it just a problem at boot time? as in, if you add "nobootwait" in the fstab and try to mount post-boot, does it work?
<BV1AL> which kernel module can enable OTG as 'host mode' ? so I can set it to load first in 'uInitrd'
<LetoThe2nd> stgraber: only talking about post-boot, its a share i want to use for data transfer
<ogra_> BV1AL, http://omappedia.org/wiki/Ubuntu_on_OMAP_FAQ#USB_OTG_port_on_PandaBoard_does_not_as_host_under_Ubuntu
<_Lucretia_> back
<BV1AL> ogra_: thanks
<BV1AL> it seems ubuntu has poor support for these devices  :(
<ogra_> feel free to help out with patches :)
<BV1AL> I mean they release those 'pre-build' images for us to download, but it's unable to run
<ogra_> ??
<ogra_> they get tested pretty heavily before being released
<LetoThe2nd> ogra_: i guess its the usual "we didn't you guess in advance what i need personally and implement it exactly that way"-bashing.
<LetoThe2nd> s/we/why/
<BV1AL> the ubuntu pre-build images just don't support OTG as host mode, so I cannot connect keyb/mouse to work on it
<ogra_> connect to the normal USB?
<ogra_> as i said, feel free to file a bug and submit a patch that fixes it
<BV1AL> the Blaze has only a OTG to connect USB devices
<ogra_> a blaze isnt a pandaboard
<BV1AL> i knew
<ogra_> if you have a blaze you should also have a contract with TI ... they provide ubuntu images adjusted for blazes
<BV1AL> so it's a proprietary developed image ?
<ogra_> no, its the same image with adjustments for the blaze
<ogra_> i.e. a different kernel that has OTG enabled i suppose
<ogra_> ask your TI representative ;)
<BV1AL> this mean I have to find my contract, then ask TI for the image to download ?
<ogra_> i guess so
<BV1AL> ok, thanks
<ogra_> the panda image works on the blaze but is definitely not optimized in any way for it
<BV1AL> I thought I can find a kernel module and put in 'uInitrd' to force it load first during bootup and enable OTG.
<ogra_> well, apparently not witzh the pandaboard kernel
<alf__> rsalveti: Hi! Are there any libgl*-sgx-omap4 packages for precise armhf (not linaro)? I can only find pvr-omap4*
<LetoThe2nd> ogra_: after reverting to backup, mount works fine. hmh.
<ogra_> LetoThe2nd, cosmic rays
<LetoThe2nd> ogra_: either that, or lack of metal mp3s on the nfs share.
<ogra_> hah
<prpplague> just fyi, there is an omap5 pandaboard wishlist thread up on the mailing list - feel free to post complaints as well - https://groups.google.com/forum/#!topic/pandaboard/mQxpEEDM6Ww
<GrueMaster> Sata, 1Gb ethernet, 2G mem, 802.11n come to mind.?
<infinity> Bazillions of gigs of RAM!
<infinity> But you already have my feedback. ;)
<GrueMaster> Sounds like someone wants to rebuild OOo.
<infinity> prpplague: Please don't ditch the DB9 serial port, unless you ship the Panda5 with a header->DB9 ribbon, so I don't have to source one.
<prpplague> please add to the thread if you have time
<ogra_> 2G mem ?
 * ogra_ just wants DRAM sockets !
<ogra_> with no limits !
<infinity> prpplague: Responded.
<prpplague> infinity: thanks
<rsalveti> alf__: the pvr-omap4 replaces the others
<rsalveti> alf__: because it uses alternatives
<rsalveti> ogra_: LetoThe2nd ^
<rsalveti> so we don't have the libgl* packages anymore
<prpplague> rsalveti: your feedback would greatly appreciated as well
<rsalveti> prpplague: oh, cool, will check
<ogra_> rsalveti, thats what i thought, thanks for confirming
<ppisati> prpplague: any ETA for this board?
 * prpplague can't make any statements on that
<prpplague> ppisati: but any info you post on the list would be extremely helpfu;
<prpplague> helpful
<prpplague> brb need food
<ppisati> prpplague: i don't have any info, i want info :)
 * ogra_ is in line with maens on the rs232 :)
<ppisati> prpplague: ram sockets, sats and pci-e
<ppisati> prpplague: that would be perfect
<ogra_> prpplague, and after spending two days to work around the USB powering (which is there for no good reason really) please done make it power through any mini USB ports
<ogra_> oh, and no microSD ...
<ogra_> i hate using adapters
<prpplague> ogra_: i did not understand your statement about usb powering
<ogra_> prpplague, you didnt read my blogpost then :)
<prpplague> ogra_: url?
<ogra_> http://ograblog.wordpress.com/2012/08/06/the-bamboo-feeder-automating-continuous-arm-image-tests/
<ogra_> the mini USB doesnt give enough current to run the board unless you roll a custom embedded kernel anyway ...  i would just drop that "feature" in the new board
<ogra_> it made a lot of sense on the beagle ... but the more power you require the less useful it is
<prpplague> ogra_: yes that is why we recommend the dual usb cable, similar to whats used on external HD's and cdroms
<prpplague> ogra_: but i am not understanding your "power cycle" issue
<ogra_> prpplague, the boards are sitting in a rack you cant really access ... the power supplies are connected to a web controlled power strip
<ogra_> if i power off the PSU, the boards stay on
<ogra_> pulling their power from mini usb
<prpplague> ogra_: they shouldn't be as long as you have the barrel jack inserted
<ogra_> well, they are
<prpplague> ogra_: even when the barrel jack is inserted?
<ogra_> well, the web controlled power strip has no robot arm attached, so yes :)
<prpplague> ogra_: well i didn't know if you were powering the board via the expansion header or via one of the other power points
<prpplague> ogra_: 4430 or 4460?
<ogra_> all of them
<ogra_> from EA1 to ES B1
<ogra_> i havent found a model that would power off in this setup
<prpplague> ogra_: i suspect there is something in your setup that i do not understand, because i regularly test panda for this specific condition
<ogra_> there is nothing to understand, use the std PSU and a usb->miniUSB cable
<prpplague> ogra_: i wish you had checked with me sooner on this
<prpplague> ogra_: yea thats how we test it
<ogra_> prpplague, i only discovered it during this project last weeks monday
<ogra_> but i can always reproduce, even with my pandas at home
<ogra_> as long as mini usb is attached they recieve power
<ogra_> no matter if i pull the barrel connector or the wall plug
<ogra_> anyway, i worked around i, works fine now :)
<ogra_> s/i/it/
<prpplague> ogra_: yea that bothers me, because we specifically test for that
<ogra_> if its actually supposed to have a switch through the barrel connector i'll happily test an EA board of omap5 if you have one :)
<prpplague> ogra_: i just tested two boards here, neither show that issue
<ogra_> funny
<prpplague> ogra_: the board is specifically designed to not allow that to happen
<prpplague> ogra_: no mods done to your boards?
<ogra_> well, what should i say
<ogra_> nope, they came freshly out of the boxes or out of bubblewrap ....
<prpplague> ogra_: interesting
<ogra_> we have several different models there
<prpplague> ogra_: i'll grab some off the assembly line for testing
<ogra_> i kept the EA1 though
<ogra_> (doesnt make sense to test on such old HW)
<prpplague> now EA1 boards might have an issue
<ogra_> well, thats why i kept it out of the loop ;)
<ogra_> the others are all ES
<ogra_> different versions though (dont ask me which, i remember an A1 and a B1, all that are in now have black PCBs)
<prpplague> ogra_: i'll rerun a bunch of tests to see if can replicate the issue
<ogra_> it works fine as it is now and i wont be able to tear it apart anymore
<ogra_> (beond me being 4000 miles away from it)
<prpplague> but i need to know why you were having that problem
<ogra_> i'll try to replicate it her tomorrow with the boards i brought back
<prpplague> ogra_: interesting
<prpplague> ogra_: i just tested A1-A4 of pandaboard
<prpplague> ogra_: all work properly
<ogra_> and let me guess, you dont get the issue
<ogra_> fun
<prpplague> ogra_: i am wondering if all of yours were made by either circuitco or svtronics
<ogra_> how would i tell ?
<ogra_> (apart from not having the boxes anymore or any physical access)
<ogra_> as i said, i can test tomorrow ... now GF calls and she will slay me if dinner gets cold ...
<prpplague> ogra_: no worries
<prpplague> ogra_: i suspect there has been an incorrect placement of a resistor on your boards
<ogra_> oh, i'm not worried, the setup works fine :)
<ogra_> and i really enjoyed doing the hw hack ...
<ogra_> nobody was injured, result was good ;)
<prpplague> ogra_: hehe, yea, just worries me
<prpplague> ogra_: i'll dig around to find out if we have a BoM issue
<GrueMaster> ogra_: My pandarack at home had the power going to the barrel connector.  I had a single AT power supply connected through a serial controlled relay.  I also had all mini-usb connectors plugged into a powered hub which was connected to my serial console server.  I used this setup to test the configuration for the build rack that davidm built, and continue to use it now (although for SETI work).
<GrueMaster> And I have several different rev boards, from EA1 to ES B1.
<ojn> GrueMaster, did you use udev to keep the machines at a stable console device number, or did you not care that they could get renumbered on reboots?
<ojn> that's my current pain point with usb-to-serial controllers as console server
<GrueMaster> ojn: for my serial console setup, I have an 8-port PCI serial interface.  Always enumerates from com4-com11 and each 9-pin end is numbered.
<GrueMaster> I didin't use the mini-usb.  OTG was too unstable between kernel rev's.
<GrueMaster> I used mini-usb as one of the two boot methods, mainly to pull a preinstalled or netboot image to SD.
<GrueMaster> I had too many issues with usb-serial cables.  1 per system is fine, 2+ becomes a headache.  I even have a 4-port usb-serial cable, but even it re-enumerates each port randomly.
<ojn> yeah. having udev handle numbering of ttyUSB* the same way ethernet interfaces are handled wouldn't be a bad idea, renaming them to new numbers and keeping them stable. :)
<ojn> seems quite doable, just never got high enough on the todo list
<infinity> ojn: It's not even remotely doable with most USB->Serial dongles, actually.
<infinity> ojn: Most have no unique identifier.
<infinity> (Unless you intentionally buy several different brands)
<scientes> just look at all the insanity in gpsd cause gps devices actually look like serial dongles
<scientes> and gpsd has to bind to all of them and figure out if they are gps devices
 * infinity vomits a little.
<ojn> infinity, hmm, i was pretty sure the ones I looked at had serial numbers. Grmbl.
<infinity> I thought I escaped modems 20 years ago.
<infinity> Apparently not.
<infinity> ojn: None of mine do.
<infinity> ojn: And GrueMaster's squid-like one with several dongles had no way to uniquely identify the tentacles.
<ojn> awesome
<infinity> It makes perfect sense, really.
<infinity> USB->serial dongles are a high-marging, low-cost part that have no REASON for someone to burn a unique ID into each one, so why would the manufacturers bother?
<infinity> The tiny subset of their customers that might care (ie: us) really aren't enough to worry about.
<infinity> s/marging/margin/
<GrueMaster> Yea, my "squid" cable was esentially a hub in the center with 4 individual serial chips (pl2303 iirc) on the ends.
<GrueMaster> If they had serial numbers in the usb device info, udev would be a no-brainer.
<GrueMaster> But I have now experienced a worse condition.  Here in my new job, I have to suffer with Windows 7.  I have two different brands of serial usb cables, neither of which have the driver cd's.  They both work in Linux w/o issues.  Windows doesn't recognise them at all.
<stgraber> VM + usb passthrough? :)
<GrueMaster> stgraber: ???
<GrueMaster> Straight Windows.  Sadly, I have had to revert to running Linux in a VM.  Only way to do decent coding.
<GrueMaster> (and ensure my boss doesn't powercycle my Linux dev system...again.
<stgraber> GrueMaster: You could run a VM on Windows using the USB passthrough feature of vmware/virtualbox to forward to the Ubuntu VM, then if the software is Windows-speciifc, run it in wine ;)
<stgraber> then no more serial driver problem
<stgraber> (though probably a whole lot of other problems)
<GrueMaster> The Windows software has a slew of incompatibilities with Wine.  Doesn't even like to run in a Windows VM (I tried).
<GrueMaster> The different programs I have to deal with are...interesting at best.
<infinity> stgraber: That's just disgusting. :P
<stgraber> infinity: well, the alternative being to write a proper universal usb serial driver for Windows, I think I prefer to use a VM and wine ;)
<GrueMaster> Meh.  I've done worse things (like running a dos envirounment in a vm under an emulator.
<infinity> I suspect said proper driver might already exist, and the "driver disks" are nothing more than .inf files.
<GrueMaster> True.  But without that inf file, you're hosed.
<infinity> Surely, the Internets can provide.
<GrueMaster> And since there are no markings on said cable, no way to look up the vendor.
<infinity> Or you can yank the USB IDs from Linux and write an INF file. :P
<GrueMaster> I looked, but all I could find were malware sites with "We can identify what drivers you need" crapware.
<GrueMaster> Still need the dll for the actual serial chip.  MOStech, iirc.
<GrueMaster> In the end, I threw the cable in the trash and went across the street to buy two new Trendnet cables.
<GrueMaster> At my salary rate, it was cheaper to get new cables.
#ubuntu-arm 2012-08-08
<danes> hello
<danes> is it possible to install windows server on a pogoplug?
<danes> is there any tutorial?
<danes> I tried archlinux but I find it difficult as I am not familiar with the commands as I am with ubuntu
<infinity> danes: Why are you asking about Windows Server here? :P
<danes> sorry, I meant ubuntu server my bad
<infinity> Anyhow, we (a) don't have kernels for them, and (b) a quick google search tells me they're v5 devices, we only support v7.
<infinity> Debian's userspace would likely work for you.
<danes> :(
<scientes> danes, debian has an installer and kernel
<infinity> (But again, no kernels, so you'd have to use the one provided by the manufacturer)
<scientes> infinity, not true
<infinity> scientes: Oh, Debian ships a kernel for them?  I stand corrected.
<scientes> http://www.cyrius.com/debian/kirkwood/sheevaplug/
<infinity> Pogo is just a rebraded sheeva?
<scientes> AFAIK
<infinity> rebranded, even.
<scientes> at least the original was
<infinity> Ahh, yeah.
<scientes> except it doesn't neccicarily come with the JTAG board
<scientes> for the serial port
<infinity> No idea what the newer ones might be, but /proc/cpuinfo from a running system would be helpful.
<infinity> danes: So, yeah.  Debian/armel would be your best bet.
<danes> thanks :)
<scientes> danes, see the bottom of this page: http://www.cyrius.com/debian/kirkwood/sheevaplug/plugs.html
<scientes> it is the sheevaplug, but lacks the jtag board
<scientes> so you can't safely change the kernel
<scientes> even if you can get root
<danes> scientes, infinity thanks guys (y)
<danes> well, I have archlinux running on it
<scientes> well the only reason its listed as "unsupported" is if you dont have access to the serial port/u-boot
<benn> hi,all. Does anybody know to know the version of armcc ?
<benn> how I can know the version of armcc ?
<scientes> benn, you mean gcc for arm?
<benn> scientes: I want to know the version of armcc in realview
<benn> scientes: but I cannot find any option like '--version' or '-V'
<scientes> i don't know what armcc is
<benn> and somebody ask me that whit is armcc v2.0
<benn> the compiler provided by arm
<scientes> just use the linaro toolchain in ubuntu
<scientes> gcc or gcc-arm-linux-gnueabihf
<benn> We are using linaro gnu toolchain. I asked this question just because somebody ask me that what is armcc v2.0 ?
<scientes> i have no idea
<benn> scientes: okay. thanks
<scientes> clang is version 3.1, and gcc is version 4.6/4.7
<aum__> Hello everyone, i have installed Pre-Installed OMAP/OMAP4 ubuntu 12.04 on begalboard its working fine. Now i have a sensor driver which compiles fine with normal gcc but when i insert it says - invalid kernel module.
<aum__> i know, i have to cross compile it, can anyone tell me how to cross compile it...
<aum__> please do suggest me how to install that driver.
<aum__> is there any other channel to discuss this kind of topic ?
<scientes> aum_ goes so fast
<LetoThe2nd> aum__: why crosscompile if you have ubuntu in place.. just compile on your beagle.
<scientes> aum__, oh hes back.... you don't need to cross compile, and you have to use the same version of the kernel to compile against, otherwise the special string in the module wont match
<aum__> LetoThe2nd, in that pricompiled image the is no arm specific compiler. normal gcc compiler compiles it though kernel rejects it to insert.
<LetoThe2nd> aum__: apt-get build-essential. done.
<aum__> scientes, can you please elaborate the process... should i compile it on begalboard itself or on another x86 desktop.?
<aum__> LetoThe2nd, i do have normal x86 gcc compiler which is not arm specific compiler
<LetoThe2nd> aum__: i doubt that *on* your beagleboard.
<LetoThe2nd> aum__: just log into the beagle, do apt-get install build-essential, compile like you would on your desktop.
<aum__> LetoThe2nd, thats what i did but the kernel rejects it to insert.
<LetoThe2nd> then the module does not fit the kernel and you have to go hunting why it doesn't, instead of talking about crosscompile magic.
<vaibhav_> aum__ even i have same problem , i m trying to compile a kernel module for arm but compilation terminates with error "scripts/recordmcount: not fount"
<vaibhav_> i have tried to generate recordmcount using "make ARCH=arm CROSSCOMPILE=arm-linux-gnueabi-  prepare " but it still not working
<djszapi> ogra_: ping
<djszapi> do you think there is an available hardware acceleration (3D, gfx) for embedded boards like the raspberry pi in case Linux?
<ogra_> djszapi, no idea, we dont support RPi, ask in an RPi channel
<janimo> ogra_, are you having nightmares involving RPi already ?
<ogra_> lol
<ogra_> no, my current nightmares revolve more around flash-kernel currently
<janimo> at one point you'll realize it's easier to bootstrap an RPi image than telling people it's unsupported :)
<ogra_> haha
<janimo> what's flash-kernel doing that's nasty?
<janimo> I finally went with modifying the precise version after talking to you last time. Works fine on the transformer
<janimo> I may look at how the quantal version needs changing
<janimo> ogra_, where do you think default bootcfg files for abootimg (and maybe similar ones for other bootloader tools) should be provided? Would flash-kernel itself not be a good container for them to have all board specifics in one package?
<ogra_> f-k 3.0 doesnt use any input config files anymore
<ogra_> you have to use abootimg directly on the boot partition to change anything
<ogra_> it doesnt currently support that for any bootloader btw
<ogra_> fo u-boot where we just switched to uEnv.txt and preEnv.txt i actually plan to store the cmdline in /etc/default/flash-kernel ... if you think we need something like that for abootimg too, we can indeed add it
<janimo> ogra_, we need something like that for abootimg right? In case the user would like to change a kernel parameter (console, rootfs) they should be able to do it just like with grub
<ogra_> well, we could also just document how to do it with abootimg
<janimo> ogra_, also something more generic than 'copy to this device' may be needed. On the transformer you actually copy the bootimg to a certain offset on the mmc
<ogra_> i think thats the debian approach
<janimo> as the boot partition is hidden
<ogra_> but yeah, i would pretty much like to have a generic place
<janimo> ogra_, so a kernel update would extract the bootimg and update the initrd and zimage in it and reuse the bootimg?
<ogra_> thats what it does on ac100 currently
<janimo> the bootimg.conf I mean
<ogra_> the cmdline is set at install time and f-k doesnt touch it
<janimo> I thought I saw it use /boot/bootimg.conf for the ac100
<janimo> on precise
<ogra_> with the pre-3.0 f-k
<ogra_> 3.0 completely changed
<ogra_> it doesnt generate boot.scr either anymore
<ogra_> only updates uImage uInitrd
<janimo> any rationale for not supporting this,is it by design  or just new codebase and noone hit this yet?
<ogra_> i think that was by design ...
<ogra_> which doenst mean we cant improve it ;)
<ogra_> as i said, for u-boot i plan to go with /etc/default/flash-kernel
<janimo> well I wonder what the rationale was, it may be something I did not think of
<ogra_> working on this over here atm
<ogra_> janimo, ask lool
<ogra_> he designed it that way
<janimo> if we can freely diverge from debian it may not be much benefit for them rearchitecting it carefully :)
<ogra_> with the new uEnv/preEnv.txt stup in u-boot its just a cat $cmdline >$preEnv.txt  ... i would like to have a similar simplicity in abootimg
<ogra_> well, we already diverted 17 versions from debian
<ogra_> and beyond things like highbank/armada support, i dont expect them to take many of tehse changes
<lool> ogra_, janimo: Essentially the idea was to live with static boot scripts as much as possible
<lool> generally flash-kernel lacks a range of functions for setting the cmdline, multiple kernels, and allowing the end-user to change these at boot time
<janimo> lool, to avoid bricking and support issues?
<lool> janimo: generally keeping it simple stupid, yes
<janimo> if defaults are simple that should work no? While allowing those who need it override the actual boot files
<lool> janimo: It's to avoid multiple code pathes
<lool> many combinations of options
<lool> also, handling of the cmdline is quite complex to do in a generic way
<lool> In Ubuntu, we only face U-Boot, but then some platforms might be using other bootloaders; then do you express the fact that some config items don't work on certain platforms?
<janimo> I am not aware of the wider set of scenarios flash-kernel is used in. On the ac100/abootimg case I do not see multiple codepaths, just a way of telling what goes into the image - every image. With a sane default and the option of editing the file thus overriding it
<lool> how do you deal with cmdline that might be set in U-Boot environment
<ogra_> well, our discussion revolves around abootimg :)
<janimo> really like grub.cfg
<lool> then there's also what do you offer in terms of cmdline: override, append, prepend, everything?
<lool> some bootloaders hardcode root= in their environment
<ogra_> same thing as grub does
<janimo> override would be the most commonly used I'd say
<lool> janimo: Yup abootimg is fairly clean there
<ogra_>  /etc/default/flash-kernel carries a single var that has the cmdline
<janimo> it is much simpler to use than uboot
<lool> there's also a default kernel cmdline in the kernel itself
<robher> lool, ogra_: in case you weren't aware u-boot supports syslinux menus now
<ogra_> robher, nice !
<lool> robher: Awesome, I've followed the email thread where missing features were discussed as well
<lool> robher: and the bug
<ogra_> but not a level of complexity i want to play with right now
<lool> I lack a bit of time to discuss this here
<lool> but I'd like to discuss a new project with you folks
<lool> it's a bit early to discuss it though
<janimo> lool, np. thanks for your input anyway
<lool> Linaro is working on a GRUB port to U-Boot
<janimo> looks like for abootimg we could do what ogra suggests without complicating the code
<lool> This would not only change the game for the flash-kernel flexibility issues I mentioned earlier
<lool> (basically flash-kernel would just be used to write a grub payload, then the usual grub configuration interface would apply)
<lool> it would also change the game around the syslinux/pxelinux compatibility problems
<robher> bugs and lacking features can be fixed...
<lool> Instead of doing pxelinux "emulation", we'd be using grub's netboot support and making sure that e.g. cobbler generates grub config giles
<lool> robher: Yes, but consider that we'll be using grub on top of uefi
<lool> and that uefi's PXE support (or basically any plain PXE implementation) isn't enough for booting a kernel with an initrd and cmdline etc.
<lool> Ok; now that I've launched this grenade, I'll go prepare a meeting   :-)
<lool> robher: I still think that it's great that we have this pxelinux "emulation" right now
<lool> robher: it's definitely a great way of delivering the feature for U-Boot platforms
<robher> so what's the pxelinux solution in an ARM UEFI world?
<lool> robher: above, I'm proposing not to use pxelinux
<lool> robher: but rather grub's script/menu config format, and implement support for that in e.g. cobbler or other places generating pxelinux ocnfigs
<lool> your DHCP server would server a pre-built grub for u-boot or grub for uefi ARM binary that would optionally bundle a config (or the config can be read from the network), the config would show a menu allowing to chose between multiple kenrel + initrd images loaded from the network
<lool> (I've also looked at the syslinux source code to check how much effort it would be to port the actual code to ARM and it would be crazy -- 12 kLOC of x86 assembly)
<lool> (reimplementing the support for the format was definitely the right thing for a pragmatic U-Boot implementation)
<robher> does grub do tftp/http loading?
<lool> robher: not http
<lool> Another option is to write another pxelinux/syslinux config parser as an UEFI application and/or as a GRUB command
<lool> but since GRUB EFI is likely to be what distros use on installed systems anyway and since GRUB has a config / script / menu language already, I personally it is a bit more natural to just generate GRUB configs
<lool> need to run, bbl
<lilstevie> speaking of grub-efi is that working with uefi on arm yet?
<janimo> ogra_, so regarding abootimg. If you add seek and bs args to the dd invocation it will be reusalbe on the tf101 too with non-zero seek offset :)
<ogra_> janimo, dd invocation ?
<ogra_> there is no dd anymore
<ogra_> just a single abootimg call
<janimo> ogra_, hmm. Not good for the tf then.
<janimo> Oh yes, I remember you directly pass the block to abootimg
<janimo> instead of using a tmpfile as in precise
<ogra_> i dont :)
<ogra_> my code used dd and created an image first ;)
<janimo> yes
<lilstevie> janimo, actually there is still a way of using it
<ogra_> thats all debians reworking that dropped this
<janimo> that woudl have worked for the tf
<janimo> lilstevie, which one?
<lilstevie> janimo, there is a hacked up driver which exposes boot/recovery
<janimo> lilstevie, ah indeed you mentioned that, and I forgot
<lilstevie> but with something like syslinux or grub on u-boot I could see that being irrelevant anyway
<janimo> that would be good. Although maybe risky to expose those, especially recovery
<lilstevie> just repartition with nvflash for initial install
<janimo> lilstevie, syslinux or grub on uboot are way in the future I guess
<lilstevie> janimo, we currently expose them in android on the tf201 in cm
<janimo> certainly not on existing hardware
<ogra_> waaaay in the future
<lilstevie> hm
<lilstevie> didn't I just read that someone cobbled syslinux menu parsing into u-boot
<ogra_> but you would need syslinux first :)
<lilstevie> ah
<lilstevie> ok I missed that, I thought it handled that part
<lilstevie> that could be nasty
<lilstevie> how is grub looking with uefi on arm? same deal?
<ogra_> janimo, anyway, my current task is /etc/default, if you want changes to abootimg handling, i'll happily take patches (or you just upload them yourself :) )
<janimo> lilstevie, having the code that exposes those extra partitions would be nice. Although it may confuse existing tools that expect certain partition naming order
<ogra_> as long as you dont break ac100 handling, feel free to change it over
<lilstevie> janimo, it tacks them to the end
<lilstevie> so no, it wouldn't
<janimo> ogra_, sure. I was saying this so you can take it into account now. If ac100 still used dd, we would not need an extra snippet for transformer, as it would be just different parameters to the same method
<janimo> lilstevie, good
<lilstevie> janimo, but more importantly tf101 gets nvflashed, which it is easy to just move the partitions to the end, rather than using hacked up drivers
<janimo> maybe the kernel solution is better
<ogra_> janimo, right, i dont mind either way
<ogra_> something like tegrapart would surely be betterm yeah
<janimo> lilstevie, not all tf can be nvflashed. Mine which is a tf101g cannot
<lilstevie> janimo, well it can
<lilstevie> just nobody has put the effort in
<janimo> well, cannot at the moment, which is what I care about :)
 * lilstevie is still waiting for someone to try and figure out how the nvflash stuff on the tf201 works and port it to other devices
<janimo> lilstevie, so that patch is like ac100's tegrapart?
<lilstevie> janimo, not exactly
<ogra_> why
<lilstevie> it hooks into the gpt driver
<Limer_> Hello, while trying to boot ubuntu-server on my pandaboard for the first time i get a blank screen. I can switch to tty2 and get a password prompt, but i don't know the password as it has not been set yet. I would really appreciate some pointers as to what might be wrong.
<GrueMaster> Limer: The server images need to run through the install setup first, which defaults to the serial console.
<GrueMaster> That will set your locale, network, system name, and user info.
<Limer> Is there a way to reach the setup without the need of a serial cable?
<infinity> Limer: If you remove the console= bits from the kernel command line, it'll stop trying to do it on serial.
<Limer> But in order to remove those i need to make a new image? It is unfortunate that the normal image isn't installable without a serial cable.
<Quintasan> infinity: Noob question, bought the damn serial cable, can't connect to the iMX though. First some message with "Broken stream" flashes and then I get "Could not find PTY". I used sudo screen /dev/ttyUSB0 115200
<infinity> Quintasan: And then screen exits?
<Quintasan> Yes
<infinity> Quintasan: If so, that's a problem with the cable/driver/host machine, not with the board.
<infinity> Quintasan: (plugging in a USB/RS-232 dongle and firing up screen on the device will "work" regardless of if you attach it to something on the other end)
<Quintasan> hurr
<Quintasan> infinity: http://wklej.org/id/806837
<infinity> Or permissions.
<Quintasan> I plugged it in and it got discovered
<Quintasan> First it didn't want to eunumerate for some reason
<infinity> Permissions will/can also be an issue.  We don't add the default user to the "dialout" group, which is required to access that device.
<infinity> "sudo adduser $me dialout" and log out/in, should that seem to be an issue for you.
<Quintasan> Yeah
<Quintasan> Not in dialout
<Quintasan> uhh
<Quintasan> infinity: http://wklej.org/id/806855
<Quintasan> Any idea why do I get that?
<Quintasan> It happens everytime I copy big stuff to sdcards
<Quintasan> like images
 * Quintasan should probably ask in #ubuntu-kernel
<infinity> Your SD cards suck.  Or your reader.  Or it's a kernel bug.
<infinity> Pick one or more of the above, season to taste.
<Limer> Time to give up on this and buy a serial-cable tomorrow ;)
<Quintasan> infinity: Oh, ok. It's class 4 SD card
<scientes> i've had really bad luck with kingston brand sd
<scientes> Quintasan, yeah you need class 10
<infinity> If you're going to rewritre frequently, I swear by Lexar (or, in fact, anything targetted at photography professionals).
<infinity> If you're writing it once, pretty much any junk will do.
<Quintasan> Will sudo screen /dev/ttyUSB0 115200 suffice to connect or I need to invoke some other black magic?
<Quintasan> bah
<infinity> Quintasan: That'll do.  No need for the sudo if you're in dialout, mind you.
<Quintasan> Stil the same error
<Quintasan> So my cable is crap
<Quintasan> Ha ha,
<Quintasan> Now it won't eunumerate
<Quintasan> infinity: THE WHOLE ARM BUSINESS IS IN CONSPIRACY AGAINST ME
 * Quintasan panics
<Limer> I feel the same way right now ;)
<Quintasan> Limer: What, another proud owner of iMX53?
<Quintasan> Or something worse?
<Limer> I am using a pandaboard, so things should work. However they don't.
<Quintasan> Logic.
<infinity> Limer: Your issue is just that the server image defaults to serial out, as we said.
<Quintasan> ARM = Automatically Rebooting Machine.
<infinity> Limer: You can change the boot.scr and fix that.
<Limer> if i change anything in boot.scr it refuses to boot at all
<infinity> Limer: Well, yes.  boot.scr has a magic binary header on it.
<Limer> What is this black magic? How can i make a boot.scr that works?
<infinity> Limer: Strip off the binary header, edit the text to be what you need, save that as, say, boot.script, then:
<infinity> mkimage -A arm -T script -C none -n "Boot Image" -d boot.script boot.scr
<infinity> mkimage is in the u-boot-tools package.
<Limer> wow, thanks a lot!
<biker_rat> Why does there seem to be a limited number of video modes availible in the linux images for my MK802?
#ubuntu-arm 2012-08-09
<rsalveti> ogra_: seems the flash-kernel hook at initramfs broke the way linaro uses to generate the image
<rsalveti> without a valid fstab, update-initramfs will be blocked at /usr/share/initramfs-tools/hooks/flash_kernel_set_root
<rsalveti> at pause_error
<rsalveti> that's just because we install the kernel and the extra packages before setting up the rootfs
<rsalveti> ogra_: while we could fix at linaro-media-create, to set up fstab before installing the packages, this would probably be an issue when using a chroot that contains a valid kernel package installed
<rsalveti> guess it'd also try to update the initramfs, and would prompt the user at the same warning message
<rsalveti> ogra_: mind reviewing the debdiff? bug 1034734
<ubot2> Launchpad bug 1034734 in flash-kernel "flash-kernel shouldn't prompt the user when updating initramfs in case there's no valid /etc/fstab" [Medium,Confirmed] https://launchpad.net/bugs/1034734
<rsalveti> I pushed a similar version at our overlay ppa and I'm finally able to get them working and booting again
<rsalveti> without this patch it'll set root as "", which it'll not end up finding the rootfs to mount at the boot
<rsalveti> janimo: probably what caused your boot issue as well ^
 * rsalveti gone
<infinity> rsalveti: fstab is the wrong place to be looking for the root device in the first place.
<janimo> rsalveti, you mean the quantal linaro image not booting? thanks
<ogra_> rsalveti, i'm working currently on changing that ;)
<janimo> infinity, thanks for the cedarview package reviews
<ogra_> rsalveti, /etc/default/flash-kernel will carry the cmdline, you can just put a default value for root= in there
<ogra_> infinity, its not wrong, it is doing what it is defined to do (there ia a switch in the db for it  that i will flick as soon as we generate proper bootloader configs again)
<infinity> ogra_: No, it's wrong regardless.  Systems can run without an fstab.  Refusing to install a bootloader because you can't be bothered to actually find the rootfs (but, instead, just trust fstab) is, well.  Wrong.
<infinity> ogra_: But I agree that the wrongness will be worked around by switching to commandline mangling.
<ogra_> not if you say that the parameter in the config will do exactly this :)
<infinity> ogra_: Still, there's no reason to hardcode / ANYWHERE.
<ogra_> once we can set Bootloader-sets-root to yes it will behave properly
<infinity> ogra_: I'd have to double-check, but I imagine update-grub does it on the fly, not from conffiles.
<ogra_> if grub has a setting "make-grub-search-for-root-in-fstab" and i set that, it is exactly what i expect it to do
<ogra_> we simply default to the equivalent option in flash-kernel atm
<ogra_> which is wrong but unavoidable until we have proper bootloader configuration in place
<infinity> ogra_: No, but I mean, when you change things to use /etc/default, you're still hardcoding the rootfs.
<ogra_> yep
<infinity> I see no reason to do that...
<ogra_> just to provie an easy way for the user to change the cmdline
<infinity> No, I'm cool with the easy way to change the commandline.
<ogra_> in a generic place all arm setups we offer has
<infinity> Not the hardcoding of the rootfs.
<ogra_> oh, i read you now
<ogra_> you want the logic from grub copied into f-k
<ogra_> or at least similar behavior ...
<infinity> Indeed.
 * ogra_ agress but doesnt want something like /etc/grub/ in the end :)
<infinity> You should be able to ship /etc/default/f-k in a way where it's the same on every normal system.
<infinity> And running f-k should "just work".
<ogra_> right
<infinity> Having the rootfs hardcoded anywhere is wrong.
<ogra_> btw ... it just struck me that all the live installer stuff i'm doing here is total nonsense
<ogra_> we just need to export FLASH_KERNEL_SKIP ...
<ogra_> (and make sure its unset when we run f-k-i)
<infinity> I still think that diverting update-initramfs and only calling it once at the end of the install is the Right Thing, optimisation-wise.
<infinity> But that's certainly not flash-kernel's job.
<ogra_> well, diverting works fine up to the point where pkgsel wants to do the same
<infinity> Yes, like I said, it shouldn't be any package's job to do it.
<ogra_> my option would be to check for an existing diversion and mangle the DIVERTS list
<infinity> It should be something the installer cleverly sorts out at a more fundamental level (as ubiquity does).
<ogra_> but that adds more code that i like to
<infinity> But, in your case, exporting a magic variable does seem much simpler. :P
<ogra_> *than
<ogra_> hmm, except that in-target doesnt seem to carry it over into the chroot
<ogra_> weird, i thought it should
<infinity> in-target just runs commands...
<infinity> chroot /target blah blah
<ogra_> yeh, i know
<infinity> That certainly won't carry an environment.
<infinity> And probably clears it intentionally.
<ogra_> thats what i mean
<infinity> Yeah, I misread the first time, and thought you were doing somehting odd like "in-target export FOO=1"
<ogra_> nope, i just set FLASH_KERNEL_SKIP=1 in the live-installer.postinst at the top
<ogra_> hmm, i should probably export as well :P
<infinity> Did you export it?
<infinity> Jinx.
 * ogra_ sighs, bug 1028905 is making me mad
<ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905
<ogra_> funnily i didnt see it once during the bamboo-feeder testing where we used rotary usb didsk ...
<ogra_> i wonder if its actually limited to flash storage by whatever reason
<infinity> Could be, it was on flash that I saw it here too.
<infinity> But... Weird, if so.
<ogra_> yep
<ogra_> yeah, exporting works fine indeed
<ogra_> infinity, hmm, so grub uses grub-probe from grub-common to find the uuid, i wonder how evil people would consider making flash-kernel depend on grub-common
<infinity> ogra_: Hah.  Seems a bit silly. ;)
<ogra_> well, grub-probe is a c binary, not sure i would want to pull something like this into f-k
<infinity> If it doesn't depend on anything else in grub-common, one could perhaps examine shipping the binary on its own.
<ogra_> (and i surely dont want to have to maintain it)
<infinity> Or something.
<ogra_> i guess we have enough scripted alternative tools to find / though
<ogra_> from where i could steal snippets and put them into f-k
<LetoThe2nd> howdy! ubuntu runs the pandaboard with the ondemand governor by default - any nice way to pin it down at 920MHz? or just hackish things?
<LetoThe2nd> modify the ondemand init script?
<Neko> LetoThe2nd, blacklist cpufreq-ondemand.ko so it can't load if it's a module (although this doesn't stop GNOME from picking it), and pick performance as a governor instead. That said, GNOME definitely forces ondemand the first time you load the power management utilities. Since Unity tends to re-use GNOME code and I think this is definitely one of the things they re-used, there's not really a good way of doing it. You could take the ondemand gover
<Neko> nor out completely though :)
<LetoThe2nd> Neko: no gnome there, its a cli only install
<Neko> oh, then nothing should try and load it if you blacklist it in theory
<rsalveti> sigh, nothing more depressing than your server's hd failing
<rsalveti> ogra_: sorry, didn't follow the entire discussion, but my issue with the current way flash-kernel is dealing with the rootfs parameter is that it replaces the one provided by the bootloader
<rsalveti> while that can fix a few cases, where the user can't change the bootloader settings, it can also cause some other side effects
<rsalveti> like not allowing the user to change the rootfs by the command line, just from the rootfs
<rsalveti> besides that, the implementation was wrong as well, fixed with my debdiff
<rsalveti> ogra_: how are you planning on fixing the issue?
<rsalveti> just because that breaks our quantal images
<ogra_> rsalveti, just edit the db entry as i described in the bug
<rsalveti> oh, will check the bug, just got on-line
<ogra_> which i will make the default once we started generating bootloader configs again
<ogra_> currently it is just set in a way that forces the lookup in fstab
<rsalveti> well, it's looking for that setting, but it's broken anyway
<ogra_> no, it isnt
<rsalveti> it fails before actually checking for Bootloader-sets-root
<rsalveti> because we don't have any fstab by the time that script runs!
<ogra_> oh, that would be broken
<ogra_> Bootloader-sets-root should definitely trigger looking for fstab
<ogra_> if thats not happening the right way, i agree it is a bug
<ogra_> Bootloader-sets-root: yes should just use whatever the bootloader config provides
<ogra_> and shouldnt use fstab or the initrd at all
<ogra_> if thats not working as expectd that needs fixing
<ogra_> the point is that we currently forcefully default to checking fstab
<ogra_> on purpose
<rsalveti> yeah
<ogra_> so the behavior is exactly what we defined in the config
<rsalveti> the patch I sent it's just makes the script to skip this setting, because in case there's no fstab, there's nothing to do
<ogra_> Bootloader-sets-root: yes looking for fstab is a bug though, but a different one
<ogra_> right, it isnt supposed to do that, since your initrd wont have the needed entry then
<rsalveti> the problem with the current code is that it checks for /etc/fstab first and then check for  Bootloader-sets-root
<ogra_> it should fail if it cant set the entry
<ogra_> right, lets fix that then
<rsalveti> ogra_: alright, let me propose a better fix then
<ogra_> suppressing something that was explicitly set isnt the solution though
<rsalveti> yup
 * ogra_ tried out postler today ... looked like an awesome minimal desktop mail client... until i found my password in clear text in ~/.config/postler :P
<Quintasan> ogra_:  :D
<infinity> ogra_: But you run full disk encryption anyway, so it doesn't matter, right? :P
<ogra_> hahaha
<infinity> ogra_: (And most mail clients store passwords in reversible hashes, it's not actually any more secure)
<ogra_> ture ... but plain text ... uh
<infinity> Plain text it just not having silly pretense.
<ogra_> and no, i dont get why anyone would use disk encryption on a home desktop
<infinity> As long as the file perms are correct, it's the same level of security as every other client.
<ogra_> ogra@anubis:~/Devel/kernels/build/ubuntu-precise-imx6-sabre-77f462e$ ls ../*deb
<ogra_> ../crypto-modules-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb  ../linux-headers-3.2.0-1001_3.2.0-1001.2_armhf.deb             ../linux-image-3.2.0-1001-imx6-sabre_3.2.0-1001.2_armhf.deb        ../nic-shared-modules-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb
<ogra_> ../kernel-image-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb    ../linux-headers-3.2.0-1001-imx6-sabre_3.2.0-1001.2_armhf.deb  ../mouse-modules-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb  ../storage-core-modules-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb
<ogra_> :D
 * ogra_ really loves that he can cross build a fully packaged kernel in 4min now :)
<ogra_> it doesnt build manyu udebs though
<ogra_> infinity, want it ? or do you build yourself anyway ?
<infinity> ogra_: I haven't built it yet, no, I'm happy to trust your binaries, if you want to toss them somewhere for me.
 * ogra_ pushes to preople.c.c
<ogra_> infinity, http://people.canonical.com/~ogra/mx6/
<ogra_> oh, nice, mx6 uses 5V 4A, i can actually use my panda PSU
<LetoThe2nd> ogra_: crossbuilding just u/zImage or a real package?
<ogra_> LetoThe2nd, the whole package ;)
<ogra_> and all its udebs
<ogra_> and headers etc
<LetoThe2nd> ogra_: mind sharing the procedure?
<LetoThe2nd> make deb-pkg is broken :(
<LetoThe2nd> jsut getting into rt-testing the omap4 and that could come in handy :)
<ogra_> i mount an 8G tmpfs, unpack the source package in there and then run:
<ogra_> DEB_BUILD_OPTIONS=parallel=8 CROSS_COMPILE=arm-linux-gnueabihf- dpkg-buildpackage -b -aarmhf
<LetoThe2nd> inside the source folder i assume?
<ogra_> yep
<LetoThe2nd> requires a debian patched kernel, i'd guess?
<ogra_> at least a debian dir, yeah
<LetoThe2nd> *notes*
<ogra_> LOL
<ogra_> that shipped microSD image for the mx6 is awesome
<ogra_> i specifically like  /viminfo and /session.vim
<ogra_> haha
<ogra_> and /root/.bash_history tells you how to play big_buck_bunny on it
<GrueMaster> ogra_: Is this a publicly available platform or is it still early?
<ogra_> GrueMaster, thats just an mx6 board someone handed to me in boston
<GrueMaster> Ah.
<ogra_> it comes with a preinstalled oneiric linaro microSd in the slot
<GrueMaster> heh
<ogra_> armel indeed :(
<ogra_> which is bad since it ships all the binardy drivers as debs in /root ...
<GrueMaster> I fount the iMX6 dev boards on Freescale's website, but no info or pics.  Just basic info and huge price tage.
<GrueMaster> s/tage/tag
<ogra_> well, quad core with sata
<ogra_> no idea what they cost
<GrueMaster> :D
<GrueMaster> The "cheapest" I see is $399 USD
<GrueMaster> So ~1.50 Euro.
<rsalveti> ogra_: the weird thing with the flash-kernel hook script is that it always expect to set the ROOT param at the initramfs
<GrueMaster> (note price adjusted for sarcastic effect).
<rsalveti> if Bootloader-sets-root is set to yes, it'll force it anyway expecting the parameter from the bootloader to be wrong
<ogra_> rsalveti, even if the confi g option is set differently ?
<rsalveti> if it's set to no, it'll provide one anyway
<rsalveti> yup
<rsalveti> ogra_: http://paste.ubuntu.com/1138037/
<ogra_> right. yes should make it ignore all root search functions
<ogra_> eek !
<ogra_> that definitely needs fixing
<rsalveti> so basically, with flash-kernel, there's no way to use the root parameter from the bootloader
<ogra_> yes, i plan hanging that by adding a function that either reads a var or determies it from the current list of mounts
<ogra_> *changing
<ogra_> not hanging :P
<rsalveti> sure, but we need to deal with this use case as well
<ogra_> in any case line 9 and 10 are horridly wrong
<rsalveti> guess the variable Bootloader-sets-root is used wrongly here
<ogra_> just remove 6-10 ?
<rsalveti> we could have one option to force the initrd to overwrite the bootloader cmdline
<rsalveti> not in case of the official and supported platforms for ubuntu
<rsalveti> but in case there's no way to chagne the bootloader settings
<ogra_> the official and supported platforms in ubuntu will have a proper config already
<rsalveti> just thinking that this would need to land at debian at some point
<rsalveti> yeah
<ogra_> flash-kernel-installer will create it
<rsalveti> actually, officially we don't need to use this hook at ubuntu
 * ogra_ really doesnt get that assumption of root=/dev/ram
<rsalveti> but it'd be nice to get it fixed anyway
<rsalveti> ogra_: in case the bootloader hardcode the root argument
<rsalveti> for some weird and bizarre values :-)
<ogra_> and ?
<ogra_> if the bootloader hardcodes /dev/ram as root= something went seriously wrong way before flash-kernel
<rsalveti> you still want to boot your distro, pointing to a different rootfs
<ogra_> and f-k shouldnt be the one working around this
<rsalveti> sure, but one workaround, and probably what was done initially at flash-kernel, is to fix that at the initrd level
<ogra_> which is just wrong
<rsalveti> not that sure
<ogra_> hardcoding your root= line in an initramfs is plainly wrong
<ogra_> if you actually *want* this and set the config to do it, thats fine, but it cant be the default
<rsalveti> yup, we should probably just use another variable
<ogra_> and if your installer did the right stuff, you will have a bootloader congif with either root=UUID= or root=/dev/whatever1
<rsalveti> Bootloader-sets-root: (required) when "yes" indicates that the   bootloader passes a root= value to the kernel and that this should be   overriden in the initrd; when "no", flash-kernel only sets a default   value for the root device, which allows end-users to pass root= to the kernel
<GrueMaster> Found it.  Expensive little beast.  http://boundarydevices.com/products/sabre-lite-imx6-sbc/
<rsalveti> Cost will be $199 in Production (October 2012)
<GrueMaster> $299 pre-production, $199 production (~10/2012)
<ogra_> rsalveti, err, wheer is that from ?
<ogra_> oh, wow
<rsalveti> ogra_: README :-)
<ogra_> i have read the README x times now
<ogra_> i never noticed the "and that this should be
<ogra_>   overriden in the initrd"
<ogra_> so yeah, definitely wrong
<ogra_> the initrd cant override, thats total nonsense
<rsalveti> not for debian I'd guess
<rsalveti> then we'd probably need to handle it differently here
<ogra_> yes
<rsalveti> probably by creating another option, or by just skipping in case it's ubuntu
<ogra_> i fear we will end up with a lot of diversion from debian again anyway
<rsalveti> like Trust-Bootloader-root :-)
<ogra_> so i dont mind mangling the "yes" case to do the right thing
<rsalveti> yeah, let me open a bug at debian about that
<ogra_> heh
<rsalveti> let me just grab some food first
<rsalveti> lunchtime
<ogra_> i doubt you will get any positive feedback :)
<prpplague> just fyi, i need all comments posted on omap5 wishlist by COB friday
<ogra_> infinity, FYI building linux-ti-omap4 on the mx6 takes 100min (i left it doing three test runs, one with parallel=8 which intrestingly took 1min longer than without)... on launchpad the saem is listed with 4h+ atm
<ogra_> *same
<infinity> ogra_: Righ, so vaguely half the time with twice the cores.  That's not unexpected for well-multithreaded builds.
<infinity> ogra_: (Which is why I'd prefer people stop using kernel builds as build benchmarks, unless that's the only thing we ever build)
<ogra_> yeah, what surprised me was that the build actually used all cfour cores regardless
<infinity> "regardless"?
<ogra_> well, even with DEB_BUILD_OPTIONS=parallel=8 which i thought might speed it up (two threads per core should be possible) the build didnt make a difference to not setting DEB_BUILD_OPTIONS
<infinity> Two threads per core definitely won't speed anything up. :P
<ogra_> well, it actually delayed it by 60sec :)
<ogra_> not significant
<infinity> Yeah, cause you cause more I/O contention.
<ogra_> still, i thought if i dont define parallel i would have expected to build single core
<infinity> Nope, cause the kernel rules file is tricky.
<ogra_> ah, it does checks ?
<infinity> If you define parallel=, it uses what you ask for, but if you don't, it uses $(getconf _NPROCESSORS_ONLN)
<ogra_> aha
<ogra_> so thats package specific, k
<infinity> Yeah.
<ogra_> well, at least we know it can build a kernel in half the time a panda can :)
<ogra_> if i find some spare time i want to try a livefs build tomorrow ... that should really fly on 60MB/s
<ogra_> i sadly cant get cooloney'S kernel to boot ...
<ogra_> i suspect the package should ship devicetree files somewhere but i cant find any
#ubuntu-arm 2012-08-10
<cooloney> ogra_: please take a look at https://wiki.linaro.org/Boards/MX6QSabreLite
<scientes> o shiii that is nice
<scientes> where can i buy it?
<scientes> cooloney, where can i get that? freescales site was not helpful
<cooloney> scientes: oh, actually i don't know how to buy it, i got it from my manager
<electronics-cat> I used the ubuntu 12.04 preinstalled omap4 linux image for the Pandaboard ES and after installing I try to install the proprietary graphics driver and it bombs out saying "SystemError: E:Unable to correct problems, you have held broken packages." Any way to fix this?
<sveinse> I'm experimenting with putting together a dummy debian package on an intel system. I call "dpkg-buildpackage -aarmel -b -us -uc -nc" which works perfectly. However if I call "dpkg-buildpackage -aarmhf -b -us -uc -nc" dh binary just returns without any errors but it does absolutely nothing and hence no package.
<ogra_> do you have the armhf cross toolchain installed ?
<sveinse> The package is debhelper based, and rules does not contain anything except a override_dh_auto_install. It never calls this in the armhf one.
<sveinse> ogra_: Yes I believe so
<ogra_> cooloney_, well, i'm just using the shipped SD card and replace uImage after i rolled a package from your git tree, i was assuming this would work, butu apparently the kernel misses DT entries
<ogra_> (at least it complains about DT stuff)
<ogra_> Error: unrecognized/unsupported machine ID (r1 = 0x00000eb9).
<ogra_> Available machine support:
<ogra_> ID (hex)        NAME
<ogra_> ffffffff        Freescale i.MX6 Quad (Device Tree)
<sveinse> ogra_: I have armhf gcc, g++ and thus libc, libstc++, binutils and so on
<ogra_> cooloney_, ^^^
<ogra_> sveinse, and the package has an entry for armhf in debian/control as well ?
<cooloney_> ogra_: yeah, it uses DT by default. i grab linaro image here http://snapshots.linaro.org/precise/pre-built/lt-mx6/236/
<ogra_> well, i want tzo use plain ubuntu images ...
<ogra_> the userspace i have is fine with the kernel from the shipped SD ...
<sveinse> ogra_. /me embarrassed. You're right. It said armel.... Thanks
<cooloney_> ogra_: after booting it up, i replace the kernel with my own built from the git tree
<ogra_> i just dont seem to be able to replace the shipped one with it
<ogra_> what mkimage command do you use ? probably i got the adresses wrong (though i picked them from the shipped kernel, they should work)
<cooloney_> mkimage -A arm -O linux -T kernel -C none -a $ADDR -e $ADDR -n "Ubuntu Kernel @$ADDR" -d $INPUT $OUTPUT
<ogra_> haha
<cooloney_> the $ADDR should be 0x10008000
<ogra_> ah, k
<sveinse> I have a somewhat hard time reading gcc specs; what is the default CFLAGS for armhf?
<sveinse> I try to cross compile x-loader and I get x-load/bu/cpu/omap3/start.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP. But I guess you don't use x-load anymore anyways...
<ogra_> cooloney_, still: Error: unrecognized/unsupported machine ID (r1 = 0x00000eb9).
<ogra_> cooloney_, right after "Starting kernel ..."
<ogra_> cooloney_, http://paste.ubuntu.com/1139260/ thats the complete boot log
<lilstevie> sveinse, from what I understand x-load is still used, just as MLO (but I might be wrong I don't own any OMAP device"
<lilstevie> )
<cooloney_> ogra_: do you have board.dtb in your mmcblk0p2?
<cooloney_> and what's your boot.scr
<ogra_> the boot.scr is the same modulo a changed root=
<cooloney_> ogra_: http://paste.ubuntu.com/1139265/, this is my boot.scr
<cooloney_> ogra_: maybe you need my uImage, boot.scr and board.dtb
<ogra_> well, i re-used the shipped boot.scr (6q_bootscript) ... that doesnt even define a .dtb
<ogra_> there is a subdir in /boot on the card that carries one though
<ogra_> cooloney_, where does the dtb come from ? i would have expected to find it in the package i built somewhere
<ogra_> ogra@sabre:~$ dpkg -c linux-image-3.2.0-1001-imx6-sabre_3.2.0-1001.2_armhf.deb|grep dtb
<ogra_> ogra@sabre:~$
<electronics-cat> smashpot mcgoo
<cooloney_> ogra_: actually i get the .dtb file from linaro image, i didn't change it
<electronics-cat> i take it proprietary powervr sgx is just broken right?
<ogra_> electronics-cat, works fine here ...
<ogra_> (at least using the integrated one (i.e. the one that you get offered via GUI right after install))
<electronics-cat> can you tell me what image you used, cause I can't get that to install at all
<ogra_> cooloney_, hmm, then let me try your boot.scr
<ogra_> electronics-cat, the default ubuntu image for 12.04 ... the hardware manager app will pop up automatically after install and offer you the PVR driver
<cooloney_> ogra_: need i sent you the board.dtb file?
<ogra_> cooloney_, well, the SD ships three, i guess if i define it in boot.scr one might work :)
<electronics-cat> ogra_: yeah it offers me the same thing, except when i try to do it, it says "SystemError: E:Unable to correct problems, you have held broken packages." after a while
<ogra_> electronics-cat, that looks more like you messed up your package manager before ...
<cooloney_> ogra_: great
<electronics-cat> ive tried it twice on a fresh install
<ogra_> you said 12.04, right ?
<ogra_> not 12.10
<electronics-cat> ubuntu-120.04-preinstalled-desktop-armhf+omap4.img
<electronics-cat> 12.04
<ogra_> and you did no fiddling, adding of any PPAs etc ?
<electronics-cat> absolutely NO fiddling at all.
<ogra_> very strange, these images get massive testing
<ogra_> cooloney_, hah, wow, of i click on "download as text" for your paste i get "DatabaseError: database disk image is malformed"
<ogra_> fun
 * ogra_ copy/pastes line by line from the html page
<cooloney_> ogra_: hah, you know i just sent your a virus in that page
<ogra_> hehe ...
<sveinse> When running armhf ubuntu, what must be armhf? I presume the bootloader can be armel, but the kernel must be armhf, right? Or will the interface between uboot and kernel fail if the eabi dont match up?
<ogra_> only the userspace needs to be hf
<sveinse> oh, I thought the kernel had to be armhf due to the userspace-kernel interface
<ogra_> cooloney_, k, none of my dtb files work, gimme yours :)
<cooloney_> ogra_: ok, will email you soon
<ogra_> thx
<sveinse> I have to admit not having total overview of what the specific differences between armel and armhf are
<sveinse> If the kernel is agnostic to armel and armhf, can a system have both armel and armhf installed via multiarch?
<ogra_> hmpf, so following the linaro instructions to reflash seems to have bricked the board
<LetoThe2nd> yay, bricking!
<cooloney_> ogra_: do you have any trick to speed up 'sbuild-update --keygen'
<cooloney_> Not enough random bytes available.  Please do some other work to give
<cooloney_> the OS a chance to collect more entropy! (Need 300 more bytes)
<ogra_> cooloney_, never used sbuild
<ogra_> better ask infinity
 * cooloney_ faint
<cooloney_> ogra_: i assume you asked me never use sbuild, hah
<ogra_> cooloney_, well, i usually just have a tarball with a chroot and manually build the package for a testbuild
<ogra_> (in there indeed)
<ogra_> i dont need any fancy buildd setup for that :)
 * ogra_ curses, so the only way to recover the mx6 is a windows tool 
<ogra_> i dont have any windows copy around :(
<ogra_> and while it runs under wine it doesnt find the usb port
<cooloney_> ogra_: oh, you broke you mx6 board?
<ogra_> i followed the linaro wiki to update the NOR bootloader
<cooloney_> ogra_: me either, i have an broken one on the desk
<ogra_> and after reboot the board is completely dead
<cooloney_> yeah, i think some boards has problem to access SD card.
<ogra_> there is a windows tool that can flash via USB to recover
<cooloney_> even I booted it up from MicroSD, I cann't read/write SD card from U-boot
<ogra_> i cant boot from anything anymore
<cooloney_> ogra_: yeah, i just gave up since no Windows PC and borrowed one board from Eric
<ogra_> hmm, there are two dip switches on the board
<ogra_> i wonder if you can influence the boot process somehow with them
<ogra_> heh, seems you can
<cooloney_> ogra_: i think fsl will try to boot SD card directly in their new board.
<cooloney_> ogra_: but for our broken board, have to use that windows tool to recover
<ogra_> sigh, finally fond an old win98 cd ... installation takes hours !
<infinity> ogra_: What on earth are you installing Win98 for?
<ogra_> infinity, to unbrick my mx6
<ogra_> infinity, i made the mistake to follow the linaro instructions to update u-boot ... even though i only copy/pasted in the u-boot shell and it all seemed to work, the board is dead now
<ogra_> and the tool FLS offers to unbrick via OTG is a windows tool
<infinity> ogra_: Sure, I get that.  It
<ogra_> i couldnt get the OTG port recognized under wine so i'm trying a vbox install now
<infinity> It's specifically "why Win98" that I was asking. :P
<lilstevie> why not xp, or something a little more modern that most people have on some machine tucked away in a corner
<lilstevie> infinity, heh I got you, I was thinking the same thing :p
<infinity> Then again, Germans are known for their masochism.
<ogra_> becuase the 98 CD is the only usable win media i found in my big brown box
<ogra_> all PCs i bought the last 15 years were whitebox products
<ogra_> so i never got any win licenses or media
<infinity> ogra_: I have several legit licenses for NT4/2K/XP/7, if you ever actually need a legit NT install sometime.
 * ogra_ had a hard time even finding a machine with usable CD rom over here
<ogra_> well, as long as vbox can natively work with USB i should be good now
<ogra_> though i might lose my left leg ... the laptop running vbox is pretty old and starts getting quite hot already
<infinity> Ugh.  I must need to go back to bed.
<infinity> I just typed by 80 bazillion character GPG passphrase into a sudo prompt SIX TIMES before I realised it wanted my password, not my passphrase. :P
<ogra_> lucky you didnt type it into IRC
<infinity> I'm tired, not mentally deficient.
 * ogra_ twiddles thumbs watching a drum and little drumsticks on the screen
<lilstevie> last time I tried to install windows in a vm it didn't work so well :(
<ogra_> works fine apparently ... but its ultra slow
<lilstevie> apparently 1.7GHz was far too much for win3.1 to handle
<ogra_> 3.1 from virtual floppies ?
<lilstevie> yeah
<ogra_> heh
 * ogra_ likes how it says "less than a minute" since 20min
<lilstevie> heh
<lilstevie> that takes me back to running on real hardware when win9x was current :p
<lilstevie> it will take 1 microsoft minute
<ogra_> heh
<ogra_> at least it has an innovative 640x480 splashscreen
<lilstevie> :D
 * lilstevie wonders how much fun it would be to install win98 natively on his current hardware
<lilstevie> 27" monitor at 2560*1440
<ogra_> argh, i thought i was done ...
<ogra_> but after first start it first wants to install drivers
<lilstevie> ah yeah, that
 * ogra_ totally forgot what a pain windows is
<lilstevie> hey, at least modern windows is a little less painful
<ogra_> but my little fried, the drum with sticks is back at least
<lilstevie> who ported tianocore uefi to the beagle btw
 * ogra_ has no idea
<lilstevie> hm
<ogra_> grrr, i forgot that adding a dns server needs a restart
<lilstevie> fun
<sveinse> What is the relationship between plymouth and libpango ?  From what I see, plymouth does not depend on libpango. However, pango files are indeed used by plymouth...
<ogra_> text rendering
<sveinse> ogra_ , yes. For some reason my lacks libpango and hence update-initramfs fails. plymouth wants to read libpango files and croaks. Isn't this an error in the deps?
<ogra_> no, thats the opposite, it prevents you from a bug :)
<ogra_> copy_exec in the plymouth hook is supposed to pull all libs in a binary is linked against
<ogra_> if it cant it has to fail, else you would be left with a non-functional initrd
<sveinse> ogra_ maybe I'm getting this all wrong, but looking at /usr/share/initramfs-tools/hooks/plymouth it refers at the bottom to pango, right. But my system has no libpango since noone depends on it.
<ogra_> plymouth does
<sveinse> uhm. not immediate/direct dependency. neither in natty nor in precise (armel) afaics. I haven't searched the dependency tree (deps of deps) thou
<sveinse> I hope I'm wrong...
<ogra_> ogra@anubis:~/Devel/packages/flash-kernel-3.0~rc.4ubuntu18$ apt-cache rdepends libpango1.0-0|grep plymouth
<ogra_>   plymouth-x11
<ogra_>   plymouth-label
<sveinse> ogra_, But that's not plymouth... Point is I'm making a theme and it depends on plymouth (only for now). Which in turn does not depend on pango even if it does use it. Now, I see that common themes usually require plymouth-label which in turn pulls in libpango. I still think this to be a bug
 * ogra_ thinks its a feature
<sveinse> well Depends on plymouth in incomplete and hereby disobeyes the Ubuntu Policy manual...
<ogra_> ??
<ogra_> initramfs-tools hooks dont obey to a packaging manual
<ogra_> they dont have to
<sveinse> Isn't the point of Depends to actually tell which packages I need to make use of this package?? "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality."
<sveinse> plymouth is broken unless libpango is installed.
<sveinse> Well, anyways. I can add plymouth-label as a dependency to my theme (even though that is not true) just to allow update-initramfs to complete
<sveinse> ogra_: No initramfs-tools hooks dont need to obey to the manual in itself, but the package system does, right? I mean the whole distribution is built upon sane dependencies
<ogra_> Recommends: plymouth-theme-ubuntu-text | plymouth-theme
<ogra_> recommends are installed by default in ubuntu
<sveinse> Ubuntu policy manual: Â§7.2 "Recommends: This declares a strong, but not absolute, dependency.". When a package become unusable because of a missing recommends package is rather stronger than recommends I'd say. But ok. I give. This is the most awkward usage of dependencies I've seen in a while.
<infinity> sveinse: If the initramfs-tools hook unconditionally copies libpango without a hard dependency, that's a bug, yes.
<sveinse> infinity: It does
<infinity> sveinse: Then please file the bug (if it's not already filed).
<sveinse> thanks, will to (tomorrow)
<sveinse> but I see ogra_'s point, if a theme requires libpango and its not there, its much better to fail during update-initramfs rather than in boot because of missing so's.
<infinity> sveinse: Sure, but either plymouth needs a dep on libpango, or how this all works needs to be made smarter.
<infinity> sveinse: Being able to install plymouth but have the initramfs-hook fail is broken behaviour.
<sveinse> infinity: My initial proposal was to test for libpango presence in initramfs-tools hook and include it conditionally. I have a theme that do not need pango, and hence that would be a better solution for me.
<sveinse> The other is to simply depend on libpango from plymouth as you said
<sveinse> Reading the hook I think it comes from an assumption that a theme always depends on libpango and hence it's present when update is run
<sveinse> Another related thing ogra_: It seems /lib/plymouth/renderers/vga16fb.so is missing from the armhf packages, while present on armel (which also croaks update-initramfs). Is this is bug as well?
<ogra_> no idea, file it and someone will look :)
<sveinse> ok, thansk
<sveinse> *thanks
<ogra_> rsalveti, poke
<rsalveti> ogra_: hey
<ogra_> rsalveti, do the ubuntu linaro images ship PVR ?
<ogra_> (the ready made img's not what i build at home with l-m-c)
<rsalveti> ogra_: yup
<ogra_> hmm, so we could do that as well in ubuntu i assume
<rsalveti> ogra_: stop updatting flash-kernel!
<rsalveti> hahah
<rsalveti> I sent a better patch yesterday
<ogra_> lol, tell rbasak
<rsalveti> need to rebase it again
<ogra_> he always complains if i break his installs !!!
<ogra_> users ...
<ogra_> *g*
<rsalveti> lol
<rsalveti> ogra_: I think the license can be an issue on a few places
<ogra_> rsalveti, well, unity-2d is considered dead now
<rsalveti> yeah, I knoe
<rsalveti> know
<ogra_> llvmpipe does apparently not work on GLES yet
<ogra_> how could you know, decision was apparently just made :)
<rsalveti> well, it was dead already, wasn't it?
 * ogra_ wants rsalveti's crystal ball !
<rsalveti> it was still around, but not maintained
<ogra_> it wasnt clear if we drop it in quantal already
<rsalveti> or you mean it's not going to be available anymore?
<ogra_> right
<ogra_> all 2D stuff will be gone from the desktop
<janimo> ogra_, since when is u-2d considered dead?
<ogra_> janimo, UDS
<rsalveti> ogra_: then we might need to include a way to install the proprietary drivers from the installer
<janimo> so u-3d will be on all CDs?
<ogra_> but back then it still sounded like it would stay around on the images in maintenance mode
<janimo> I thought so far that u-2d would eventually replace the compiz based one :)
<ogra_> which was apparently just decided to not happen
<ogra_> janimo, we all hoped that :)
<janimo> link to ml discussion or irclogs? I did not follow much of desktop recently
<janimo> besides UDS talks I mean
<ogra_> rsalveti, well, if you could ship them, we can as well, we just need to make sure ubiquity still works in framebuffer, i dont see a way to boot a live image and use dkms
<ogra_> janimo, nope, there were no discussions at all apart from UDS :/
<janimo> ok, since you said above 'was just decided'  I though very recently
<rsalveti> hm, I don't see why we'd be using gles from the start
<rsalveti> gles/opengle
<rsalveti> I we had plans to put wayland right at initrd :-)
<ogra_> janimo, yes, the actual decision to drop it asap was made just now
<rsalveti> but that was just one part afaik
<ogra_> i dont see wayland as the default in quantal
<janimo> because of the qt uncertainty or just carrying two similar codebases is not worth it
<ogra_> nor do i see space on the images to ship it
<ogra_> (in parallel with xorg)
 * ogra_ hugs jcrigby ... thanks for the upload !
<rsalveti> so framebuffer will still be an option for the installer, right?
<ogra_> rsalveti, i hope so
<rsalveti> ogra_: bug 1034734, a new debdiff for you sr
<ubot2> Launchpad bug 1034734 in flash-kernel "flash-kernel shouldn't prompt the user when updating initramfs in case there's no valid /etc/fstab" [Medium,Confirmed] https://launchpad.net/bugs/1034734
<ogra_> uness they decide the slideshow needs to be in clutter or some other evil thing
<rsalveti> ogra_: please review it :-)
<rsalveti> ogra_: lol
<rsalveti> would not be surprised
<rsalveti> boot log in 3d, fancy installer
<rsalveti> that's the future
<rsalveti> :-)
<ogra_> rsalveti, hmm, thats the third place we set FLASH_KERNEL_SKIP now
<ogra_> i wonder if we cant do it more globally
<rsalveti> ogra_: yup
<rsalveti> ogra_: well, this is a hook for initramfs
<ogra_> like in the flash-kernel script itself probably :)
<rsalveti> so it's not actually running flash-kernel
<ogra_> (where we did it in the past)
<rsalveti> but more like, please don't mess with my system in case I don't want to run flash-kernel
<rsalveti> :-)
<rsalveti> but I understood why we had 2 options yesterday on that crazy if block
<ogra_> yep
<rsalveti> one is setting the root to overwrite the one provided by the kernel
<rsalveti> and the other just to provide a default
<ogra_> yeah, and we want the latter
<rsalveti> yup
<rsalveti> so if we keep as 'no', it'll behave as we want
<ogra_> we will default to yes though
<rsalveti> why?
<ogra_> as soon as i changed f-k-i to create a proper default config
<rsalveti> the yes is to replace the rootfs parameter from the boot loader
<rsalveti> there's no need to do it
<ogra_> because by default ubuntu sets root=UUID= on the cmdline
<ogra_> we dont want to have an initrd override that
<rsalveti> sure, and that's why you actually want a no here
<ogra_> no, we want a yes :)
<rsalveti> no means it'll set a default root argument at the initramfs, that will not replace the one from the kernel
<ogra_> if yes, then the bootloader sets the root parameter
<rsalveti> no!
<rsalveti> :-)
<ogra_> if no, flash-kernel tiresd to set it in initrd
<rsalveti> check the readme
<rsalveti> Bootloader-sets-root: (required) when "yes" indicates that the bootloader passes a root= value to the kernel and that this should be overriden in the initrd; when "no", flash-kernel only sets a default value for the root device, which allows end-users to pass root= to the kernel.
<rsalveti> so 'no' is what we want at ubuntu
<rsalveti> and my patch fixes the behavior to match exactly as we need
<infinity> My god, that's an unintuitively-named option.
<rsalveti> infinity: exactly!
<ogra_> ++
<infinity> It should be "Initrd-overrides-root"
<ogra_> talk to the linaro OCTO :P
<rsalveti> lool: ^
<rsalveti> your fault
<rsalveti> :P
<ogra_> its *all* his fault !
<rsalveti> it's your baby, you created the new monster
<lool> infinity: No, right now it's implemented with initrd, but with some boards it might set root in e.g. bootloader environment  :-)
<lool> rsalveti: ^  :-)
<rsalveti> exactly
<rsalveti> but here
<rsalveti> we have the bootloader setting the rootfs
<rsalveti> and we don't want that to be forced by the initramfs
<lool> rsalveti: I've read the patch earlier today, but I didn't really see all the use cases for both adding the SKIP support (ok with that) *and* the other code changes
<lool> rsalveti: Sure, so you want Blst: no
<rsalveti> one, without /etc/fstab
<rsalveti> currently if you don't have a /etc/fstab it'll break and explode to the user
<lool> rsalveti: not having a fstab is bad; why not have one?
<rsalveti> lool: chroot?
<lool> so you disable flash-kernel until you have one
<lool> why do you need flash-kernel in a chroot?  :-)
<rsalveti> why disabling flash-kernel?
<rsalveti> well, not sure, why not?
<rsalveti> this I got because of the way linaro-media-create runs
<rsalveti> it sets the /etc/fstab as the last step in the game
<rsalveti> can be changed, but where I got the issue
<ogra_> rsalveti, if you dont disable it it will try to write to the defined device
<rsalveti> still, it should deal with the situation where no rootfs can be found at /etc/fstab
<rsalveti> breaking and asking for user input is bad
<lool> rsalveti: I don't like the user input thing, I agree, it's historical, but breaking the install by default kind of make sense to me
<lool> *makes
<lool> rather than silently resulting in an unbootable system
<rsalveti> lool: that's why I'm now breaking in case we have a "yes" and we don't have a rootfs
<rsalveti> if we have a "no" we don't actually care
<lool> rsalveti: l-m-c should have a step to install packages and a separate one to "make the system bootable", just like during an install
<ogra_> lool, will you be at UDS btw ?
<ogra_> we have patches piling up again and i think we shoudl sit down and look whats acceptable for debian and what needs to stay ubuntu only
<lool> rsalveti: One thing which might not be obvious: Blsr is just a cosmetic thing for how the root is set by f-k, in *both* cases f-k needs to know the root dev
<lool> ogra_: which one?
<ogra_> next one
<lool> ogra_: I'll be in Copenhagen
<ogra_> great
<rsalveti> lool: well, it doesn't need to know, that's the thing
<rsalveti> lool: not at ubuntu at least
<ogra_> lool, so mark 1h for f-k discussion over a beer or wine then ;)
<rsalveti> if we're dealing with the rootfs argument by ourself, we don't want flash-kernel to mess with it
<rsalveti> it tries to provide a default one, but if it can't find a rootfs, it'll just skip it
<rsalveti> that's why I changed at my patch
<rsalveti> *what
<rsalveti> I don't know why the decision was made to always have a working rootfs at initrd
<rsalveti> I know that the use case 'yes' here is valid
<lool> rsalveti: I'm not sure it's a good direction; f-k knows a bit too little about the boot details at the moment, moving towards it knowing less for certain devices isn't great   :-/
<rsalveti> but still, you're forcing the rootfs argument to the user
<rsalveti> lool: why not?
<lool> rsalveti: the system should know about the boot and root devices
<rsalveti> that's just the rootfs argument
<lool> rsalveti: I don't undertsand "you're forcing the rootfs argument to the user"?
<lool> ogra_: if I do that we're going to drink wine or beer for one hour  ;-)
<rsalveti> well, by forcing a rootfs argument at the initrd, that also replaces the one provided by the kernel
<lool> rsalveti: It's not necessarily forced
<rsalveti> it is
<lool> rsalveti: one code path only sets a default
<rsalveti> just in case it's a 'no'
<lool> rsalveti: that's the point of Blsr
<lool> rsalveti: Yes
<lool> rsalveti: The reason this exists is because some bootloaders hardcode it without f-k being able to update this
<rsalveti> sure, but here you're assuming you know which bootloader is used
<lool> e.g. some systems hardcode root=/dev/ram/ram0, others hardcode /dev/hda1 when you want /dev/sda1 or /dev/md0 etc.
<rsalveti> and that can be updated
<rsalveti> *it can't
<lool> rsalveti: I'm explaining where the feature comes from
<rsalveti> I hate this idea of the system setting everything up for the user, and forcing him to use such options
<rsalveti> if he wants to change the rootfs, it'll be a huge pain
<lool> rsalveti: Now, rather than always overriding the kernel root=, it was considered a good idea to only override it if it's hardcoded
<lool> rsalveti: hold on
<lool> rsalveti: I think you're jumping to conclusions
<rsalveti> no, it's just weird we're assuming that for a few devices the user will not be able to update the bootloader
<rsalveti> or the bootloader arguments
<lool> Now that I've explained where this comes from, when I moved this option from an "if" in the code to the database, I also looked at the code and tried to make everything as automatic and config-less as possible
<lool> I'm sure there are advanced use cases that were never well supported and that we should try to support
<lool> But I'd like to support these use cases in a solid and maintainable (upgradeable) way
<ogra_> lool, i think if f-k is configured to not handle root= it should simply not handle it at all
<lool> rsalveti: It's exactly that: for certain devices, we can't update the bootloader settings or the bootloader
<rsalveti> I understand, but it can be quite confusing as well
<rsalveti> it's hard for the user to understand that the initrd is replacing his own kernel options
<lool> rsalveti: it might be because it's too risky to do so, because the sources are ancient / hard to build / missing, or because the feature is lacking
<ogra_> the current behavior makes it still fiddle with it
<rsalveti> and that's not explicitly happening
<lool> rsalveti: I understand, this is a historical implementation which has some advantages, let's think of how we can provide alternate options?
<rsalveti> with the 'yes' path I'd be just happy if we had a *big* warning saying to the user that the system is now controlling the rootfs argument
<rsalveti> and for the 'no' case, please don't do anything :-)
<rsalveti> which is what we want at ubuntu
<lool> rsalveti: I disagree
<lool> I don't think we want to do nothing wiht Ubuntu
<ogra_> we do :)
<lool> we should speak of concrete system-wide use cases rather than just thinking at the f-k level
<rsalveti> at ubuntu we want a file to control the rootfs argument
<ogra_> we want to put root=UUID= in place from f-k-i
<lool> if you do nothing you end up with a kernel panic because no root= is set
<infinity> lool: For Ubuntu, hardcoding rootfs in an initrd is wrong, period.  Distro initrds should be generic.
<ogra_> as we always did
<lool> rsalveti: Yup, that's valid
<rsalveti> in our case, it's the boot.src
<rsalveti> uEnv or similar
<infinity> lool: If I move my rootfs from one disk to another, and update my kernel cmdline, it should Just Work.
<lool> infinity: generic distro initrds are just a NTH IMO
<ogra_> we have them on x86
<ogra_> and i even can use my omap4 initrds on my ac100
<lool> I can give you higher priority features that are missing such as supporting multiple kernels
<infinity> We can and should have them anywhere where the bootloader can set the kernel cmdline.
<ogra_> as long as i dont make use of modules
<rsalveti> initrd should be mostly generic
<rsalveti> and will be generic once we have a single zimage
<rsalveti> adding other options based on different systems, is wrong
<rsalveti> unless there's  no way to support
<infinity> rsalveti: I don't mean generic across subarches (though that will be nice when subarches go away), I mean system-independant.
<rsalveti> and even with that, we should have a huge warning to the user
<lool> Folks, I agree with your goals but I'll play devil's advocate: some Debian-supported devices have limited storage for the initrd and can only deal with MODULES=dep
<rsalveti> because it breaks the default logic from the initrd
<lool> this makes the initrd non-generic
<infinity> An initrd generated on my Panda booting from /dev/sdb1 should work on another Panda booting from /dev/sda2.
<ogra_> lool, some ubuntu ones too
<infinity> lool: That's subarch.
<infinity> lool: Maybe the word I want here is "portable", not "generic".
<infinity> Hardcoding filesystem localtion in an initrd breaks portability.
<infinity> location, too.
<rsalveti> ++
<lool> In any case, I'm happy to note down "We want initrd to be as generic as possible, if the boards allow"
<lool> as a goal
<ogra_> lool, no... "we dont want f-k to make any use of the initrd if we told it not to"
<ogra_> with emphasis on "any"
<lool> this is not a feature
<infinity> It's an anti-feature, which is even better. :P
<ogra_> no, its a bug :)
<infinity> Less is more.
<ogra_> at least the current behavior is
<lool> please
<infinity> It's not flash-kernel's job to find the root filesystem, it's the initrd's job, in a generalised fashion.  Yes, in weird corner cases where you MUST override the kernel cmdline, sure, having that option is cool.
<ogra_> i agree that rsalveti shouldnt run f-k in a chroot but i also agree that f-k should mess with the initrd if the bootloader sets the root
<ogra_> *shouldnt
<infinity> But it's by no means the default state of affairs.  We trust out kernel cmdline, generally.
<lool> infinity: GRUB knows my root device
<infinity> lool: Yes, GRUB is your bootloader, and it's setting the cmdline.
<lool> GRUB sets my kernel cmdline
<ogra_> boot.scr and uEnv.txt do too
<lool> yes
<infinity> lool: f-k isn't a bootloader.
<lool> No, but it also is in charge of making the system bootable
<ogra_> it is in charge of putting the bits and pieces in the right places
<infinity> lool: And, hence, it should set bits for u-boot systems, and not hardcode the same in the initrd.
<ogra_> and in case of f-k-i i agree its in charge of doing initial configuration
<lool> infinity: Yes, I agree that we could have a more specialized / more clever approach on U-Boot systems
<lool> it's painful though
<infinity> lool: Yes, I understand this can't work this way everywhere.  That's no excuse for not doing it right where it can work.
<lool> but I'd like us to move to that
<lool> infinity: I'm not looking for excuses here, I'm explaining where the current implementation comes from
<lool> I'm not saying we should keep it forever like this, I'm explaining why it's currently like this
<lool> and trying to understand the use cases so that we have a design to handle them, rather than workarounds for the current limitations
<lool> for instance, one thing which we could do is generate boot.scr or uEnv.txt with a root= in them, and have a f-k config file with a root fs override
<ogra_> lool, thats the plan on my side
<lool> or we could have a setting to ignore that the root device mentioned in fstab is missing
<rsalveti> the two ones I wanted to fix is, please don't stop to the user in case it can't find the rootfs while updating the initramfs, and the other is please don't do anything in case we have a 'no' here :-)
<lool> rsalveti: I don't think it's a good idea not to have a fstab though
<rsalveti> and at ubuntu we'll mostly just support devices with a 'no'
<infinity> lool: Not having an fstab actually works perfectly fine, it's not required.
<lool> rsalveti: So what's the scenario for updating the initramfs somewhere else?
<infinity> lool: And it's certainly not required to list / in fstab.
<ogra_> lool, having /etc/default/flash-kernel carrying the distro defaults, if f-k runs we have a detection that merged root= with this and creates a preEnv.txt
<rsalveti> lool: so if for some reason, I install flash-kernel into a chroot, I can't update initramfs
<rsalveti> let's suppose I want to mount the sd card somewhere
<rsalveti> and change something, or even update the initrd
<rsalveti> I can't!
<lool> infinity: An initrd shouldn't be required either, yet f-k assumes one right now
<rsalveti> because it'll break and warn me that it could not find the original rootfs device
<lool> infinity: And you're not required to run a linux kernel either
<ogra_> rsalveti, your chroot tool should set FLASH_KERNEL_SKIP
<lool> in fact you could be booting Windows with flash-kernel, if you spend sufficient time porting it
<ogra_> thats why we invented it
<rsalveti> ogra_: that's also what I added to the patch
<lool> seriously, let's stick to the useful questions  :-)
<infinity> lool: Erm.  "Not relying on the contents of fstab" is perfectly reasonable and useful, unlike discussing booting Windows. :P
<rsalveti> but still, it should't break unless it's really needed
<rsalveti> unless we have a 'yes'
<lool> rsalveti: So assuming you want to update the initrd on some other device, how would you set the target device?
<ogra_> it should no-op actually
<rsalveti> mounting the sd card at a different machine and updating the initrd is a quite solid use case
<lool> rsalveti: Would we need some env var to chose it?
<rsalveti> that the user shouldn't need to set any skip variable
<lool> rsalveti: (For the case where some devices require a custom initrd)
<lool> infinity: If we're designing a production system for end-users, it should have a fstab like standard system do
<rsalveti> lool: then it needs to be run at the device, or break to the user warning that the rootfs can't be found
<rsalveti> but not on all use cases
<rsalveti> that's what I'm saying
<lool> that's needed to pickup mount options, for fsck etc.
<rsalveti> and that's what I changed at my patch :-)
<infinity> lool: The "standard system" doesn't rely on the fstab to set up the bootloader.
<infinity> lool: (By standard here, I mean "x86")
 * infinity shrugs.
<lool> infinity: no but it relies on a fstab being present
<infinity> I've been pushing back against people who want to embed fstab snippets in initrds for other reasons, I'm irked to see it happen here.
<lool> anyway, I don't think we need to spend out energy on the least useful case of supporting fstab-less systems; it's more important to fix the use case preventing e.g. Ricardo to create images
<infinity> This isn't about specialised devices or doing things between subarches, those are straw men.  An initrd generated on omap4 should work on any machine with a matching kernel.
<lool> infinity: Keep in mind it's historical; I'm happy if we implement ways to avoid it in the future
<rsalveti> lool: so please take my patch! :-)
<rsalveti> I think we should go into 2 steps here
<rsalveti> one is making sure we're not breaking anything with the current implementaiton
<rsalveti> and later fixing it properly, like not depending on fstab
<lool> I think we shouldn't mix all problems in this IRC discussion, it's also getting close to diner for me (in fact I tried to run away an hour ago, but was pulled into another chat with Zach :-)
<rsalveti> but for ubuntu this case is not relevant I believe, because I don't think we'll support devices that forces the rootfs argument
<rsalveti> but I could be wrong
<lool> rsalveti: That's right
<ogra_> we'll have a detection routine that sets the UUID in ubuntu
<lool> rsalveti: Also a while ago ogra_ told me that he wanted support for initrd-less booting for Ubuntu
<ogra_> right
<lool> (I don't remember why that was needed, but ISTR there was a valid reason)
<rsalveti> well, I believe that's supported already
<rsalveti> at least for 12.04
<ogra_> we just want the option as we have on all other arches
<rsalveti> but yeah, it'll break the ones that needs the 'yes' here, as for that we'd need an initrd anyway
<lool> maybe in Ubuntu's f-k, I don't think it's the case in Debian's
<ogra_> since i merged 3.0 its not the case in ubuntu
<ogra_> but its planned to be changed before FF
<lool> rsalveti: Ok; diner is ready here now, could we discuss your specific problem(s) and get over the patch together next week?
<rsalveti> lool: sure, that's covered at the bug already, but if needed we can discuss it properly again
<rsalveti> if you can just reply it later on it'd help already
<lool> rsalveti: Would it be worth a bug that l-m-c doesn't generate the fstab before making the system bootable?
<rsalveti> not that sure, that shouldn't be a requirement
<rsalveti> that's my point
<rsalveti> we don't support devices that we can't control the bootloader
<infinity> If you're building, say, a bootable installer, you *can't* generate a valid fstab before making the image bootable.
<rsalveti> ogra_: the only thing that we probably need to check again with current debian implementation is that they are supporting device tree already
<infinity> You generate the fstab at install time.  Y'know, after you've booted.
<rsalveti> at the 3.2 version
<infinity> (Granted, in these cases, we hand-craft the boot bits, and ignore f-k entirely)
<ogra_> rsalveti, well we surely dont support it yet
<rsalveti> so we want to make sure we try to avoid duplication here
<rsalveti> but we'll need to support I believe
<ogra_> i just fell over that when trying my mx6 board (before i briked it hard following the linaro instructions)
<ogra_> that wikipage should get a big fat warning btw
<rsalveti> ogra_: that's why my heads up :-)
<rsalveti> ogra_: yup =\
<lool> infinity: But then don't run flash-kernel in it (SKIP=yes) -- I'm fine with the SKIP use case
<lool> that is, I'm fine with install the flash-kernel package with SKIP=yes, and then run flash-kernel when deploying on the device to make the device bootable
<lool> rsalveti: Hmm I think you're envisioning the installer as running flash-kernel *and* setting up u-boot files, while I envision flash-kernel to also setup the u-boot files if needed
<ogra_> setting up should only be happening by f-k-i
<lool> ogra_: Wow, how did you manage to brick your board?
<ogra_> f-k should only update
<ogra_> lool, by following the linaro wiki (copy/paste)
<ogra_> https://wiki.linaro.org/Boards/MX6QSabreLite
<lool> ogra_: why did it get bricked?
<ogra_> sudo dd if=iMX6DQ_SPI_to_uSDHC3.bin of=/dev/sdx ... then boot with this in the slot ... and copy paste the 5 lines into the u-boot shell
<ogra_> that will tell you it successfully updated and crc checked etc ... and after that the board is dead
<ogra_> i got the windows unbrick tool but lacka proper windows that can see raw usb devices to fix it ...
<ogra_> (my weekend homework)
<lool> ogra_: but is it because the files are for another board?
<ogra_> its a sabrelite
<ogra_> not sure if there are many iterations of it
<ogra_> but i wouldnt think so
<ogra_> i even have the same u-boot prompt (not that this says much)
<ogra_> s/have/had/
<GrueMaster> ogra_: Try Win32ImageWriter?
#ubuntu-arm 2012-08-12
<daurnimator> I'm trying to run es2gears on my beagleboard; and it segfaults
<daurnimator> (soft float)
<ogra_> armel (soft float) isnt really maintained anymore, but you could indeed file a bug
<daurnimator> luckily the one piece of software left I depend on released a hard float version a couple of days ago :)
<daurnimator> so maybe I can move to hf
<ogra_> you should ... though there is no hf pvbr driver for omap3 in the archive yet
<ogra_> *pvr
<daurnimator> pvbr?
<daurnimator> still.... pvr?
<ogra_> (not sure if we'll ever get it)
<ogra_> yes, that was a typo (thus the * correction later)
<daurnimator> I know. but I still don't know what pvr means
<ogra_> the gles driver
<daurnimator> ah...
<daurnimator> that sounds bad
<daurnimator> my problem atm is that scaling my Qt application; X uses 40% CPU
<ogra_> well, complain to TI
<ogra_> we can only release what they give out and we havent recieverd a hf driver binary from them yet
<daurnimator> ogra_: the sgx binaries I see mentioned here aren't all you need? http://www.elinux.org/BeagleBoardUbuntu#SGX_Video_Acceleration
<daurnimator> "Thanks to TI for the special armhf binaries!!! --RobertCNelson 19:48, 17 July 2012 (UTC)"
<ogra_> ah, yeah, thats the one
<daurnimator> though I'm not exactly sure about the instructions... I have to compile my own kernel to use those drivers??/
<daurnimator> ogra_: do you know who I could talk to about my problem on armel though?
#ubuntu-arm 2013-08-06
<snkt> hiii
<ellery_> When trying to boot Ubuntu on an embedded platform with multiple drives, is it possible to specify which drive is to be used for creating the RFS?
#ubuntu-arm 2013-08-07
<kulve> now I have debian stable running on Ouya with all the tegra binary blobs. Performance seems nice for the price, although there is still couple of annoying bugs
#ubuntu-arm 2013-08-08
<saiarcot895> Hi, I need some help on understanding why an error occurs
<saiarcot895> In the OpenSceneGraph build log for Saucy (https://launchpadlibrarian.net/147019889/buildlog_ubuntu-saucy-armhf.openscenegraph_3.0.1-4.1_FAILEDTOBUILD.txt.gz) there are a few lines towards the end basically saying that there are conflicting definitions of variables
<saiarcot895> this error doesn't occur on i386 or amd64; why does it occur on armhf?
<tinti> mfisch: ping
<mfisch> tinti: pong
<tinti> mfisch: hi, is there any official channel for ubuntu-edge and ubuntu-for-android?
<mfisch> tinti: #ubuntu-touch for the edge, there is no channel for Ubuntu for Android
<tinti> mfisch: ok, thanks for the great job :)
<tinti> the reddit was very good
<andrewsmith> i don't understand
<andrew_> which server this is on
<andrewsmith> ubuntu
<andrew_> or freenode?
<k1l> ubuntu is a redirect to freenode
<andrewsmith> ah, cool, thanks
#ubuntu-arm 2013-08-10
<Tassadar_> hi, is there somebody who knows how ARM kernels boot? "params_phys" is not defined in Makefile.boot for my device, does that mean it doesn't use atags or is some default value used?
#ubuntu-arm 2013-08-11
<kulve> http://tuomas.kulve.fi/blog/2013/08/11/debian-on-ouya/
#ubuntu-arm 2014-08-06
<ogra_> bug #1326200
#ubuntu-arm 2015-08-03
<akegalj> does anyone have experiance cloning microSD card for udoo board?
<akegalj> after cloning my udoo board is in semi corupted state
#ubuntu-arm 2016-08-10
<Nishikino-Maki> what is Ubuntu software center package name call?
<Nishikino-Maki> i mean in 'sudo apt-get install xxxxx'
<patrask> is the main-repo for ARM not officially supported by the security team?
