#ubuntu-arm 2009-03-16
<dave_m> #ubuntu-devel
<lool> Excellent choice
<armin76> rofl
<Martyn> Morning.
<Martyn> Well, afternoon now.
<Martyn> ogra : Could I entice you to make an image that boots to single-user for me?   We're still waiting for the serial breakout dongle, and I want to run some benchmarks that get skewed if X is loaded.
<Martyn> Well, wait, not single user .. just X-less
 * Martyn tried hex editing the Redboot sector in the image that has the kernel command line, but if you even touch a single byte of it, the board doesn't boot.
 * Martyn is now working on getting u-boot functioning
<Martyn> hey all
<Martyn> Anyone working on the mx51 platform awake?
<lool> Martyn: Shortly
<Martyn> Ping me when you're ready to talk u-boot and kernels :)
<lool> Martyn: Concerning RedBoot config, it's checksummed; I can hand you a C version of "fconfig", but it's not able to change settings
<lool> Martyn: Eh, it's a tad late for me
<lool> Martyn: Concerning U-Boot, you have anything working yet?
<Martyn> lool : I know.  What I need then is an image that has "text" appended to the kernel command line...
<lool> I'm working on a Perl version of fconfig, but was distracted today
<Martyn> lool : Somewhat.  I can now load the kernel image into RAM from the SD card, but cannot execute.  I need to read through the MX's massive documentation to see what I'm doing wrong.
<lool> I just got the checksum working thursday
<Martyn> I cannot load the initrd into ram however.
<Martyn> lool : cksum on u-boot :)  Woot.
<lool> No, of the redboot config
<Martyn> I've also poked at my higher-ups (aka, CEO) to get cracking on getting better communication between canonical and us, so we can talk more freely.
<lool> Martyn: I know we had issues with initramfs earlier, but it should be all working now
<Martyn> lool : Gotcha.  hopefully ogra will have a new sdcard image built soon then.
<Martyn> I'm going to keep picking away at u-boot till it works, since that's the more "standard" bootloader on ARM these days.
<Martyn> and it would be nice to have an in-firmware monitor.
<lool> Hmm that's harder I think
 * lool waves and goes away for tonight
<armin76> Martyn: afaik freescale is working on porting it to u-boot, or something i read on the powerdeveloper site
<Martyn> armin76 : Do you have a link to the powerdeveloper article?
<armin76> sec
<armin76> Martyn: http://www.powerdeveloper.org/forums/viewtopic.php?p=12019
<armin76> read the part Genesi and Freescale will be responsible for the Firmware...
<Martyn> Heh.
<Martyn> "Please don't submit projects to port u-boot, as Freescale will be handling this themselves...."
<Martyn> *chuckle*
<Martyn> good lord .. some of those proposals date back to 2004 :)
<Martyn> You'd think they would have gotten u-boot working from the theoretical to the actual in five years :)
<armin76> Martyn: i think you're reading on the efika
<armin76> or pegasos
#ubuntu-arm 2009-03-17
<lool> Oh we have two ARM emulators for FSL devices in the archive outside of Qemu
<lool> softgun can emulate imx21 and can run redboot
<ogra> even the imx51 one ?
<ogra> that would be perfect for setting up the images
<lool> No, just imx21
<lool> Hmm /me just realized something really stupid   :-/
<ogra> good that you relized it :)
<lool> My perl implementation of fconfig is falling short in front of redboot storing IP addresses and ESA addresses as the bytes of the raw C data structure
<ogra> *realized
<lool> I don't see how I'll match that in perl
<ogra> didnt you have that C tool ?
<ogra> from the source you Ã¼pÃ¼ointed me to
<lool> I had a C tool, but it was crap
<lool> For fconfig
<lool> I started fixing it for a bunch of things, but I gave up when faced with fitting in the addition / changing of values
<lool> ogra: 14:40 < lool> I started fixing it for a bunch of things, but I gave up when  faced with fitting in the addition / changing of values
<persia> lool, Can't you use pack() and unpack() to replicate a struct?
<lool> persia: I can, but the struct might change from platform to platform
<lool> it's supposed to be opaque
<persia> Oh, yeah.  If the struct isn't constructed in such a way to be independent, then you're out of luck :(
<Martyn> Good morning
<lool> persia: Yes, that's exactly the problem; even the on-flash format for a *bool* can vary between 2 and 4 bytes, depending on sizeof(bool)...
<lool> A bool!
<lool> 4 bytes!
<Martyn> Yep.
<Martyn> lool : Well, depending on the platform, compiler, etc... sure.
<Martyn> lool : These days, where people are no longer thinking in therms of bits and bytes, but rather kilo and mega ... to those developers, why not use an int for a bool?   *sigh*
<Martyn> I'm not saying it's right, mind you .. just that it's common.
<Martyn> lool : You'll cry .. but on the PS2, on that cell processor ... a bool takes up a whopping full 128 bits.
<Martyn> There are app notes that say "if you need a boolean, consider allocating an int and using flags..."
<ogra> lool, well, indeed TRUE is four letters ... :)
<Martyn> ogra : *groan*
<Martyn> ogra : So, I'm still stuck without a serial dongle for the board for at least another week.   Is there any possibility I could get you to make an image that has the redboot kernel cmdline settings appended with "text"?
<Martyn> ogra : Since the Redboot does hash itself, and thus I can't twiddle the bits manually at the moment with a hex editor...
<ogra> yes, i saw your question, but sorry, i have to much on my plate atm trying to get a new image with a new kernel up
<Martyn> *nod*
<Martyn> So, before I poke into this any deeper.. I thought Freescale had committed to porting u-boot (albeit this was posted on a forum back in '04) ... do you know if they are still responsible for it?
<Martyn> ogra: Are you using a modified Redboot?
<Martyn> Actually, that's a general Q to anyone...
<ogra> i'm using the one from NCommander (which he packaged already but which didnt hit the archive yet)
 * NCommander returns
<lool> Martyn: The FSL one
<NCommander> wooo, ecosconfig-imx was accepted!
<armin76> Martyn: what? '04?
<lool> persia: Well concerning IP addresses, I was wrong, the format isn't too crazy as under linux typedef uint32_t in_addr_t
<armin76> Martyn: i don't think the post i passed to you is from that date
<armin76> haha
<Martyn> armin76 : Yep, twas.
<armin76> Martyn: you saw the registration date of the guy who posted it
<Martyn> Ah :)
<armin76> not the date of the post
<armin76> http://www.powerdeveloper.org/forums/viewtopic.php?p=12019
<NCommander> yay for X hanging
<armin76> Posted: Tue Jan 27, 2009 4:25 pm    Post subject: i.MX515 Project Guidelines
<armin76> Martyn: ^ :)
<ogra> NCommander, did you see my question on the redboot package ?
<NCommander> ogra, no I didn't
<ogra> it looks like ecosconfig and redboot come from the same tarball, is that right ?
<NCommander> ogra, no, separate
<ogra> ok
<ogra> phew
<NCommander> Well ... upstream has them together
<NCommander> freescale has them seperate
<ogra> eeek
<ogra> thats what i asked about
<NCommander> I think the version FSL has is before they were merged
<NCommander> Because when I worked on the NSLU2 RedBoot, they were also separate
<ogra> ok
<NCommander> ogra, its kinda weird :-/. If you want to look for yourself, in the redboot zip, the config tools are in tools/ecos_config_tools, and then I built a tarball out of the redboot code and patches out of the stuff in source
<ogra> no, its fine, i just wanted to know if they were one tarball when you recieved them
<NCommander> ogra, well, it was the giant zip from hell :-)
<Martyn> NCommander : I need to change the redboot config in ogra's image .. would you be so kind as to link or send me the zip?
<ogra> if its a) the tarball for ecosconfig and b) the content of the zip tarred up for redboot, thats fine
<NCommander> Martyn, pull the packages out of my PPA, ecosconfig-imx, and redboot-imx
<NCommander> You need to build on an ARM machine with an arm-gnueabi-linux toolchain.
<Martyn> What's the address for your PPA?
<Martyn> I need to add you to the sources.list
<NCommander> Martyn, https://edge.launchpad.net/~mcasadevall/+archive/ppa
<NCommander> Martyn, its a devirtualized PPA so you can also pull binaries down for it on ARM (since you need to build on ARM if you want to just use debuild)
<NCommander> Martyn, what configuration change to you want to make?
<NCommander> Martyn, http://wiki.ubuntu.com/ARM/BuildingBabbageRedBoot - this will likely help you
<Martyn> got it.
<Martyn> ogra : Is the default installed gcc on your image the eabi toolchain?
<Martyn> installed/installable
<NCommander> Martyn, no, this RedBoot been modified to use a linux toolchain vs. an eabi
<NCommander> It won't compile with an eabi toolchain.
<Martyn> foobie.
<NCommander> foobie?
<NCommander> Martyn, what are you trying to do?
<Martyn> Heh, that's what my young cousin used to say when she tried to say "fubar"
<Martyn> NCommander : My babbage shipped without the JTAG/serial dongle.  I want to start ogra's live image in text, rather than full X mode
<NCommander> Oh
<Martyn> The tests I'm running need as much free RAM as possible, and the board only has 512...
<NCommander> The config line isn't in the source code, its in the config partition of the image.
 * NCommander notes that its possible to telnet into RedBoot over ethernet, but those options in ogra's image are off.
<Martyn> Right, and you can't change the partition of the image by hand (it's hashed, and if changed will prevent booting)
<NCommander> Martyn, lool was working on a tool to do just that
<Martyn> Yep, it's not ready yet that I know it.
<Martyn> it/of
<armin76> Martyn: what kind of serial does it need?
<ogra> armin76, a specially developed external board
<ogra> with mxcuart chip
<lool> Hmm problem
<armin76> oh...
<lool> fconfig includes the MAC address
<lool> Found key :fec_esa_data: of type :6: sensing :fec_esa: with data length 8; value:42:00:00:EA:18:F0:
<ogra> do we care `
<ogra> ?
<NCommander> mine isn't set right and it works
<NCommander> we're not using the ethernet port during boot.
<ogra> right
<lool> Yes, but if we keep the SD card for booting, it will have broken networking
<lool> (in redboot only of course)
<Martyn> Only temporarily
<Martyn> right
<lool> Is the ethernet address correctly detected on boot by linux?
<ogra> lool, and who cares ?
 * ogra cant check atm
<ogra> but if not we can generate one randomly
<Martyn> the mac address is stored in the chip, and is read by the driver early on for most adapters...
<Martyn> ogra : Indeed.  As long as you don't use the reserved 00:00:00:00:00:00 address ... it should work fine.
<ogra> right
<Martyn> although generating a random one each boot, may confuse an upstream switch :)
<ogra> well, it should have at least the venmdor part set by default
<Martyn> and it is present on the chip anyway.   When linux comes up, the driver will set the mac correctly.
 * NCommander wonders if he should strip out some of the ecos source thats unused
<NCommander> The copyright file is a freaking mess :-/
<lool> Martyn: Well sometimes the linux driver just relies on the hardware as initialized by the boot loader to know its MAC
<lool> I know some d-i platforms are parsing the MAC address from the bootloader data
<lool> NCommander: yeah for ecosconfig \o/
<NCommander> lool, RedBoot is done aside from its copyright file (which just broke 130 lines :-/)
<lool> NCommander: You complain about 130 lines of copyright, I'd like to complain about my stupid 600 lines of perl
<lool> Perl seemed like a good choice, but I'm not sure it was
<NCommander> lool, what are you coding in perl?
<ogra> shell FTW !
<lool> Still on fconfig
 * NCommander would have choosen C and canobolized the existing code.
<lool> ogra: I'm confident it was a better choice than shell for this task   :-)
<ogra> nah
<ogra> :)
<NCommander> autoconf has long providen you can do ANYTHING in sh
<lool> One reason it's useful to have it in C (and not C++ or Perl or anything) is to have it in an initrd rootfs; otherwise the libs suck a lot of space
<lool> NCommander: Yeah, and it has "providen" that it's ugly and nobody gets it right too  :-P
<ogra> you think to far in advance
<lool> ogra: That's actually the reason fis.cpp was rewritten in C for NSLU2  :-)
<ogra> we really dont need it in initramfs atm
<ogra> its enough to have it in the rootfs
<lool> ogra: I'm just mentionning it for completeness in this discussion; I do think there could be value in having it in initramfs for d-i
<lool> Anyway
<lool> I can parse the full config now; let's write it from scratch
<ogra> d-i is out of scope as well for jaunty
<ogra> all we wnat is to write the initial config and the initramfs and kernel binaries to SD for now
<lool> Yes
<lool> ogra: Would have I thought of that though, I would have pursued the C version, as ugly as it was, or rewritten one
<ogra> thats what i thought you were doing until this morning
 * ogra curses ... no input possibility in the latest kernel
<lool> ogra: A C version?
<ogra> lool, the tool you pointed me to the other day
<lool> ogra: Well the fconfig one was awful in the implementation
<ogra> but it worked ?
<lool> I fixed it up for the read code path, but the write code path was too awful
<lool> ogra: It didn't have any write support and that required a lot of things
<ogra> hmm, i thought the site you pointed me to talked about write support
<lool> ogra: For fis.c probably
<ogra> right
<lool> ogra: Two different upstreams
<lool> fconfig is wholy different
<lool> It's a separate project
<lool> I found 3 fis implementations and one fconfig one; the fconfig one was the problematic one
<lool> Well TBH I'm not perfectly happy with the fis ones, but it's ok, we can use them as is
<ogra> 	fputs("Read, write or list Redboot configuration\n", stdout);
<ogra> 	fputs("usage: fconfig [-r|-w|-l]"
<ogra> 	      " -d dev -o offset -n nickname -x value\n", stdout);
<ogra> 	fputs("'dev' may be a char device, block device or a file\n", stdout);
<ogra> 	fputs("'offset' is the offset in bytes on the device\n", stdout);
<ogra> 	fputs("Supported types: \n", stdout);
<ogra> 	for (i = 0; i < NUM_TYPES; i++) {
<ogra> 		printf(" - %s\n", TYPE_NAME(i));
<ogra> 	}
<ogra> 	fputs("Additional switches: \n", stdout);
<ogra> 	fputs(" -v:\tVerbose mode, use more to increase verbosity\n", stdout);
<ogra> 	fputs(" -s:\tSilent mode, absolutely no messages printed\n", stdout);
<ogra> thats what i see in the source
<ogra> i would have expected -w to be "write"
<lool> Yes, but it overwrites an existing config with the same config
<ogra> ugh
<lool> Exactly what I said: "ugh" :)
<NCommander> ugh
 * NCommander prays he's wrong
<ogra> gramattically your ugh looks right :)
<NCommander> lool, ogra, we've got a problem :-/
<NCommander> The RedBoot/ecos tree has 4 clause BSD code intermixed with GPLv2 code.
 * ogra has lots of problems toiday ... no news
<ogra> fis create initramfs
<ogra> whoops ... wrong focus
 * NCommander sighs, and takes a look upstream
<lool> NCommander: Hmpf
<lool> NCommander: Where exactly is the 4-clause BSD?
<NCommander> lool, its the ecos network stack, I don't think I can rip it out.
<NCommander> (it looks like someone copy and pasted an older version of the OpenBSD stack ...)
<NCommander> Before they made the change to a newer BSD license (the copyright notices are 1992-1993)
<lool> NCommander: Is this an upstream issue?
<NCommander> Looks like, I'm poking ecos's CVS repo to see if it was resolved in a later version
<lool> Even RedBoot bits are 4-clause, such as packages/redboot/current/include/net/tftp.h
<lool> NCommander: it was not
<NCommander> so its still an issue upstream?
<lool> NCommander: So 1) bring it up on the upstream list 2) mention the issue on debian/copyright and the fact that you contacted upstream about it
<lool> NCommander: It's still an issue upstream
<lool> Well from a checkout some days old, but it doesn't change much
<ogra> worst case it forces the packages to restricted
<NCommander> Er, lool, GPLv2 and BSD 4-clause are incompatible; you can't license code together.
<NCommander> The two licenses conflict with each other ...
<lool> NCommander: But ECos folks did and RedBoot has been shipping in millions of devices
<ogra> right
 * NCommander remembers he was asked this question on his P&P for NM ...
<NCommander> I thought the adversing clause constitued an additional restriction which breaks the GPL.
<ogra> debian ...
<lool> NCommander: It does
<NCommander> I'm lost then ...
<lool> ogra: Did you start looking into cdimage bits for SD card images for babbage?
<lool> NCommander: Where is the redboot source you're using ATM?
<NCommander> lool, on my HDD.
<NCommander> lool, I'm uploading a copy to REVU in a few minutes
<lool> NCommander: I just need to check values of redboot configs; any older version is fine
<lool> I'm grabbing redboot-imx from your ppa
<NCommander> lool, that's fine.
 * NCommander is just determining if this package is going to universe or to multiverse
<NCommander> I don't think we have anything in main with four-clause BSD (which could be problematic for anyone adversing), but on the flip side, debian-legal says 4-clause BSD can go in main
<NCommander> (debian main)
 * lool curses Xorg crashes when doing development
<NCommander> lool, I'm suffering from the random USB device insertions taking X down.
<Martyn> Is there a full ubuntu 9.04 live image available for the OMAP3 evm board built by mistral?
 * Martyn reads through the scrollback ... 
 * Martyn is with ogra -- shell FTW
<Martyn> NCommander : You have it right.  4-clause and GPL are mutually incompatible
<Martyn> NCommander : LGPL and 4-clause may be compatible, depending.
<NCommander> Martyn, there is an exception in the GPL code in this package to allow it to be linked.
<Martyn> NCommander: Sounds like the lesser GPL then
<NCommander> Martyn, no, its GPL with an exception clause
<NCommander> (there is a difference)
<Martyn> Weird.
<Martyn> Cool but weird :)
 * Martyn doesn't care about the licenses much when developing .. I just Want It To Work(tm)
<Martyn> If it means I have a rewrite a section of code afterwards, the development goes faster.
<Martyn> ogra : I may have a network driver bug to report.   Should I post it to Launchpad?
<Martyn> Rx stops completely, and in a way I can reproduce, when fragmented packets are present.
<Martyn> (I've been doing some lighttpd load testing.  It occurs on the Babbage, but not on the EVM or Beagle)
<Martyn> Tx still sends packets, Rx does not receive any, and ifconfig reports no further packets being counted.
<faso> Hi All...I am trying to get jaunty on my N810
<faso> I am trying to follow instructions http://www.internettablettalk.com/forums/showthread.php?t=25975...
<faso> I am unable to do debootstrap
<faso> I wonder why
<faso> appreciate any help?
<NCommander> faso, what was the error?
<faso> actually I am unable to locate debootstrap in any of the repositories
<faso> Do u know where I can install it from
<faso> ?
<lool> faso: It's in all Ubuntus
<lool> I mean available to them
#ubuntu-arm 2009-03-18
<Guest74361> Anyone else nutty enough to be awake now?
<Meiz_n810> Is there a vfp-support currently?
<ogra> lool the cdimage scripts shuldnt differ from the USB key scripts, essentially i thought: create an empty image with n MB sized redboot partition and ext2 or vfat partition ... grab the existing live .img file and copy the content into the second partition ... set up redboot with kernel, initramfs and fconfig
<lool> ogra: How do you grab redboot?
<ogra> from the archive
<ogra> its in since some hours
<lool> ogra: So you have full archive access and can unpack any .deb
<lool> ogra: You don't particularly need .udebs for instance
<ogra> i should, shouldnt i ?
<lool> ogra: I don't know
<lool> ogra: I'm not touching cdimage stuff
<ogra> i think i do :)
<lool> Meiz_n810: What do you mean?
<lool> ogra: Are you running under hardy?
<ogra> udebs -> yes, for the bootloader installation in ubiquity
<lool> ogra: On x86?
<ogra> shouldnt matter as long as i can access the jaunty archive and pull the redboot binary from there
<ogra> (and indeed your scripts need to be able to run under hardy)
<lool> ogra: Do you think we have time to complete ubiquity support for redboot?  I really fear we don't, it involves creating a partition for redboot and kernel and all, that means partman changes and it's notoriously hard
<ogra> right, that brings us back to the casper bootmenu idea
<lool> ogra: So fis is a C program currently, should I also port that to perl or will you rebuild a version for hardy or...?
<ogra> which i'm not actually happy about since we cant upgrade the kernel without trashing our install media
<ogra> no idea, you havent shown me any code yet
<lool> ogra: I just had an idea for this, but it's not very elegant
<ogra> thats fine
<ogra> its our first shot and we're late
<ogra> elegance is for karmic
<lool> ogra: Well the fis code isn't mine, it's the public one I mentionned a couple of weeks ago; I didn't think of the constraints of running on cdimage which I'm asserting now
<lool> I can show you code right now if you like, but the question stands on whether a C binary is enough or not
<lool> Or whether I should look at rewriting that in perl as well
<ogra> i would assume so
<ogra> can it build under x86 ?
<lool> ogra: So do you typically run hand-build binaries on cdimage, or does 99.9% of the tools come from hardy package or...?
<ogra> (and still function)
<lool> fis.c builds and runs under amd64 which is where I've been running it
<ogra> ok
<ogra> we shopuld just add your stiff to NCommander's redboot-imx package i think
<lool> ogra: Well I wondered the same, but I thought that while we're likely to drop the redboot package when we get a real board, we're unlikely to drop the utilities to update data
<ogra> then the script can pull it from the archive, dpkg -x it and call the binaries as well as dd'ing redboot
<lool> ogra: That is, I expect we will want to manipulate fis data and fconfig data, probably in the installer, but less so that we will ship redboot
<lool> ogra: But it's just a guess, happy to hear what you think
<lool> I'm happy if I can skip NEW
<ogra> yes, thats my final target
<ogra> but i'm not sure we really want it for jaunty
<lool> dpkg -x => I'm not sure, it's going to be built agianst jaunty's libc6; it should work, but it's not very clean
<ogra> (i'm not sure we really can do it in time for jaunty rather)
<lool> Ok, I agree with the last comment (ENOTIME); having it in redboot is not too ugly for jaunty and saves us time
<ogra> if we could loop mount the squashfs we shouldnt need to care about jaunty/hardy
<lool> I was having nightmares this night that I still needed to package redboot-utils, file a FFE, promote to main etc.
<ogra> since we can run inside a jaunty chroot
<ogra> oh, wait, we cant
<lool> Err armel?
<ogra> cdimage is x86
<ogra> yeah
<ogra> grrr
<lool> That's why I'm asking so much about cdimage environment; it's not clear what are the allowed custom behavior, and how much self-contained the archive needs to be for that
<ogra> well, my main prob is that i still have no functional kernel, i need that first before actually making build scripts
<ogra> we definately need to be able to pull the tools we use from the archive
<lool> ogra: Well I think we need to make progress on cdimage integration no matter what; I can provide you with a binary image of fconfig data while I complete the script hopefully today
<ogra> so adding your stuff to the redboot package should be the next step
<ogra> right
<lool> Ok; I can add fis today and whatever I have for fconfig as well, I think I'll move from "clean implementation" mode to "I need this tonight"
<ogra> i hope the latest kernel doesnt oops and leaves me with working ttys, if that works i can start the actual final scripting tomorrow
<ogra> sadly the kernel testing eats immense amounts of time atm
<lool> ogra: So who will write the image creation script?  I know what needs to be done, but not where to do it, and prefer if you do it and I tell you what needs to be done at a high level
<ogra> that somewhat blocks me
<ogra> right, i can do it with your guidance and probably a bit of StevenK handholing, that shouldnt be a big prob
<lool> ogra: Let's leave the kernel to the kernel team, the kernel shows console message which is enough to confirm our kernels are properly loaded in the SD image; we can hand replace them with a working one
<ogra> no
<lool> Why not?
<ogra> i need it to work with casper
<ogra> it doesnt help to just see it booting
<ogra> we need to be sure we get through initramfs
<ogra> and i would like to actually test the images
<lool> ogra: What I'm saying is that we have working kernels
<lool> older ones
<lool> Oh ok, I get it with initramfs
<ogra> currently my only working kernel isnt one thats coming from any of our packages
<lool> Ok, nevermind
<lool> ogra: But it's good enough to develop the SD image building script itself
<lool> ogra: It's not a large work, but I'd feel better if we'd start its implementation now
<ogra> sure, but then there is nobody who will weed out the tty bug
<ogra> currently we have no kernel that boots into a usable system
<lool> ogra: Ok; please hand me the LP #, I'll sub to it; is it milestoned?
<ogra> and i would really like to make sure that works first
<ogra> there is no LP#
<lool> ogra: Perhaps we need to ring the alarm bell with the imx51 kernel that we need kernel efforts now?
<ogra> amitk is doing his best
<ogra> i'm confident we'll have it solved today
<lool> ogra: Well if it's a blocker, we certainly need it tracked a milestoned jaunty bug
<lool> amitk: What do you think?
<lool> ogra: Let's imagine a second it wont be fixed today, we'd be better off with a bug than without, do you agree?
<ogra> (my prob is that i still dont exactly know where the sigkill of the shell comes from)
<ogra> yes, for the sigkill we need a bug
<lool> ogra: Ok; would you mind filing this bug (these bugs)?  after we're done discussing?
<ogra> sure, will do
<ogra> he prob is that we have nothing in the archive yet i can actually point to
<lool> ogra: It's not affecting the current jaunty stuff?
<ogra> all the work we're doing on the kernel comes from uploads amitk does to people.u.c
<ogra> it is
<lool> ogra: File it against jaunty then?  either getty or bash, or just ubuntu; it's just to document the existence and status of this issue
<ogra> the uploaded kernel in the archive only has the inital code drop from freescale in it but no adjustments towards the actual ubuntu kernels
<ogra> as soon as amitk started to build it like a common ubuntu kernel the probs showed up
<lool> ogra: If I want to ring the alarm bell, I need a bug id to point at
<lool> Even if this is "about to be merged" work
<ogra> i'm confident its a linux issue ...
<ogra> since it works with all non-ubutuized kernels
<ogra> and it might even be caused by the cross toolchain amitk uses
<lool> ogra: Concerning udebs, do you think it makes sense to have a d-i build for imx51?
<lool> Well for babbage actually
<ogra> sure, now that NCommander is free he can care for it if he likes
<lool> I think it's the obvious place to provide a SD card image with kernel + initrd with d-i, but I don't think it's required if we do live
<ogra> he seemed to have some special interest in alternate images
<lool> NCommander: What are you looking into ATM?  Could you take that?
<ogra> (i guess an answer will take some hours :) )
<lool> NCommander: Also, kexec-tools was finally added to P-a-s, do you think you could try it out?  it built on armel
<lool> ogra: Ok; let's move to the actual SD card script
<ogra> heh, kexec-tools bit me in a funny way yesterday
<lool> ogra: So first thing, we need an empty partition table which sadly encodes info about CHS; I think we want them maxed as to allow covering of most SD cards
<ogra> no
<ogra> we want a generic part. table and an image thats not bigger than needed
<lool> ogra: How does it differ from what I'm saying?
<ogra> why do you want to have CHS ?
<ogra> just dd an empty image and call a simple fdisk or sfdisk script on it to create two partitions
<lool> ogra: The partition table defines the cylinder size in bytes
<ogra> hmm
<lool> ogra: Don't worry about it; it's easy
<ogra> ok
<lool> hold on, I actually have a good pointer
<lool> Sorry, I don't find the URL right now; it was on the TI site explaining how to format a SD card for beagle/evm
<ogra> easiest would be to pre-create a binary blob
<ogra> with partition table and redboot already
<lool> ogra: I don't think that's a good idea
<ogra> why ?
<lool> ogra: Where do you store that?
<lool> If it's generated data, let's generate it?
<lool> It's not hard to script fdisk
<ogra> we pre create binary squashfs images for the livecd as well
<lool> Automatically
<ogra> i dont say we shouldnt generate itr
<lool> Oh ok
<ogra> just saying dd -> build image, dd -> binary blob to that image -> mcopy livefs ... or somethng like that
<amitk> lool: I am ok with ringing the alarm bell. A 3rd person looking at it certainly can't do any harm
<lool> ogra: So back to creating SD images: 10) create a large file which is going to be the SD card image; size is size of squashfs rounded up to a number of cylinders + size of FIS partition rounded up to a number of cylinders + size of partition table
<ogra> i would say we're fine with 800M
<ogra> though our current livefs doesnt include oo.o
<ogra> but its about 510M big
<lool> ogra: 20) format that with fdisk, using the same values as for beagleboard images (I think it's 63/63/63 or 255/255/255); craete partition 1 just as large as FIS size rounded up and partition 2 of size rounded up to to hold squashds
<lool> Type of first partition should be non-FS data, type of second partition should be linux
<ogra> right
<ogra> preferably formatted as vfat since we can skip loop mounting with that
<lool> 30) run ./fis init with proper arguments on first partition to create an empty FIS part table
<lool> 40) create a file of the size of the redboot config fis partition (4096) and fconfig -i it with proper arguments (this I hope to provide tonight)
<ogra> right
<lool> 50) ./fis create with proper arguments the 5 FIS partitions: RedBoot, FIS directory, RedBoot config, kernel
<lool> You need to pass the file contents for that step, so for instance for the kernel fis partition you need to pass the kernel image to ./fis so that it can checksum it
<ogra> indeed, so we need to dpkg -x it
<ogra> oh, wait
<lool> *perhaps* -- but I'm not sure -- you need to prepare a null-padded file with the kernel + zeroes or kernel + 0xff's and pass that to ./fis instead
<ogra> we should be able to pull it out of the livecd image
<ogra> it has initramfs and kernel now that we added imx51 to it
<lool> ogra: That's an option
<ogra> the only one :)
<ogra> we need a casper initramfs
<lool> Concerning that optional padding, I think only initramfs is sensible to that
<ogra> built on armel
<lool> Are the optional padding step and step 50 clear to you?
<amitk> ogra: the toolchain is a good point. Now if lool or someone can point me to a ubuntu toolchain I can use, I would try it
<ogra> relatively, gimme the tool ... :)
<lool> 60) You actually need to dd the data files your passed to ./fis in the relevant places, that is in the FIS partition offset in the first DOS partition: ./fis create does *not* copy the file's contents, it only write the FIS directory entry
<lool> 70) write the squashfs data to the second DOS partition
<lool> done
<lool> ogra: Sure
<lool> ogra: http://svn.nslu2-linux.org/svnroot/fis/trunk/
<lool> Just make
<ogra> well for 70 i would just mcopy the whole content 1:1 from the livecd image
<lool> Doesn't require anything fancy, should work with hardy
<ogra> amitk, shell still dies, still no input via USB kbd
<lool> ogra: Concerning fconfig, I recommend you dd the contents from an existing SD image for now, but I can provide fconfig.pl which can not write the data yet to you if you like
<lool> amitk: You could try building natively, push to the canonical-arm-dev ppa
<ogra> no, finish it first
<ogra> amitk, #32 Tue Mar 17 20:18:30 EET 2009 is the right timestamp ?
<ogra> (just to make sure)
<lool> ogra: I couldn't find the exact page I found in the past, I think it moved, but this page has comparable instructions: http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat
<lool> ogra: Basically, it's fdisk 'o' command to create an empty partition, then 'x' for expert mode, and '255/63/<smallest number of cylinders you needs>'
<lool> People who want to use the SD card for other stuff will have to fix that last number to match their card's size in bytes
<lool> (well in cylinders)
<amitk> ogra: that timestamp looks right
<ogra> easy to put into a here document with fdisk ...
<lool> amitk, ogra: Would be nice to push the kernel to the ppa to let it build natively and exclude the toolchain and that one of you would file the bug documenting the issue(s) so that we can ask for more people to reproduce and look into it
<lool> I prefer focusing on my own stuff than acting as a relay here as I have much to do still
<ogra> toolchain is a close indicatior given that klogd also dies
<amitk> lool: what is the url to the ppa, I can't seem to find it
<lool> amitk: It's a private PPA
<lool> ogra: Do you think you have enough that you can start working on the script while trying out new kernels from amitk?
<ogra> yep
<ogra> lool, its not clear to me yet how redboot will find the partition, but thats a prob for later, let me get started first
 * ogra is afk for a moment
<lool> ogra: RedBoot expects it at a given offset
<lool> ogra: This is hardcoded:
<lool> RedBoot           0x00000000  0x00000000  0x00040000  0x00000000
<lool> FIS directory     0x00040000  0x00000000  0x0001F000  0x00000000
<lool> We could *perhaps* change some stuff such as sizes, but I wouldn't count on that
<lool> We don't need to anyway
<lool> This is probably not hardcoded but I wouldn't want to deviate on it either:
<lool> RedBoot config    0x0005F000  0x0005F000  0x00000000  0x00000000
<lool> The rest is ours to define
<lool> For my 16M SD card, I picked kernel size == 0x00400000 and initrd size == 0x00940000
<lool> It's quite arbitrary, and we should probably make it larger to target >= 32M for boot data, we target large cards anyway
<lool> http://paste.ubuntu.com/132944/ was my final layout
<lool> ogra: For my installed system, I did this: http://paste.ubuntu.com/132945/ note that I created a swap partition which might make sense here as well
<ogra> well, i dont want to trash peoples SD cards by using swap ... and the 512M of the babbage really suffice
<lool> Ok
<ogra> (and we have compcache for people really wanting swap)
<ogra> amitk, i get the following now:  "usbhid: disagrees about version of symbol struct_module"
<ogra> amitk, and an actual "invalid module format" message
<amitk> grr..
<amitk> I have just uploaded to the ppa
<lool> 49C0BED7.5080205@visionsystems.de
<ogra> ok
<ogra> i'll wait until it built
<lool> NCommander: you might be interested in the above message to linux-arm-kernel
<amitk> ogra: for some reason I think you have a module mismatch during creation of initramfs
<ogra> i wouldnt know why
<ogra> it is the initramfs created by the linux-image postinst, nothing fancy about it
<ogra> and i also get it if i boot without initramfs
<ogra> i.e. if the modules come from disk
<ogra> well, not exactly the same message though
<ogra> [42949400.560000] sg: disagrees about version of symbol struct_module
<ogra> [42949401.040000] sg: disagrees about version of symbol struct_module
<ogra> [42949401.530000] usbhid: disagrees about version of symbol struct_module
<ogra> [42949401.680000] usbhid: disagrees about version of symbol struct_module
<amitk> lool: Rejected:
<amitk> PPA exceeded its size limit (1284.00 of 1024.00 MiB). Ask a question in https://answers.launchpad.net/soyuz/ if you need more space.
<lool> uhoh
<ogra> gah
<amitk> lool: can you kill the old kernel?
<ogra> isnt there some older image we can drop
<lool> #  152 binary packages (1.1 GiB)
<lool> https://answers.launchpad.net/soyuz/+question/64519
<lool> NCommander: I removed your kernel from the PPA, please reupload it when we get more space (see above question)
<lool> amitk: I think you can reupload
<lool> #  51 binary packages (1.1 GiB)
<lool> I fear it's openjdk spoiling it
<ogra> hmm, all files in /lib/modules have 1970-01-01 as timestamp ...
<ogra> i wonder if that confuses anything
<amitk> interesting
<ogra> well, when i installed the package i had to use a very old kernel that didnt have hwclock working
<ogra> root@babbage:~# modprobe usbhid
<ogra> FATAL: Error inserting usbhid (/lib/modules/2.6.28-10-imx51/kernel/drivers/hid/usbhid/usbhid.ko): Invalid module format
<ogra> root@babbage:~# uname -a
<ogra> Linux babbage 2.6.28-10-imx51 #32 Tue Mar 17 17:28:59 EET 2009 armv7l GNU/Linux
 * ogra rm -f's /lib/modules/2.6.28-10-imx51 and reinstalls the package
<ogra> root@babbage:~# modprobe usbhid
<ogra> FATAL: Error inserting usbhid (/lib/modules/2.6.28-10-imx51/kernel/drivers/hid/usbhid/usbhid.ko): Invalid module format
<ogra> same ...
<ogra> amitk, the timestamps on the module binaries definately match the timestamp of the vmlinuz binary
<ogra> -rw-r--r-- 1 root root 2158304 2009-03-17 19:30 vmlinuz-2.6.28-10-imx51
<ogra> -rw-r--r-- 1 root root 49056 2009-03-17 19:30 /lib/modules/2.6.28-10-imx51/kernel/ubuntu/squashfs/squashfs.ko
<ogra> so it really has to do something with the build
<error404notfound> has anybody tried installing ubuntu on http://uniconsys.com/index.php/platforms/products-pegasus
<Martyn> Good morning :)
<dave_m_> Martyn: Hi - this is Dave Martin btw.
<Martyn> hey there dave :)
<Martyn> good talking to you :)
<armin76> :)
<Martyn> So, I tried to get a telnet-enabled Redboot working using fsl-redboot.  So far, no luck.
<lool> Martyn: What's the actual problem?
<Martyn> re ogra
<Martyn> lool : No response at all.
<Martyn> lool : Not an electronic sausage
<Martyn> for mx51, should I be grabbing packages from ports.ubuntu?
<ogra> yep
<ogra> feel free to use the rootfs-from-scratch script in the topic
<ogra> it will roll you a ready to use tarball
<Martyn> done :)
<Martyn> Have you had success using the telnet features of the fsl redboot ogra?
<Martyn> I try to get the adapter up and running, but cannot make a connection
<ogra> no, i'm only focusing on serial and direct write access
<Martyn> *nod*
<ogra> we'll get the latter the next days
<ogra> which might solve your probs as well
<Martyn> Okay :)  someone's already on it.
<Martyn> I got the serial/JTAG dongle today from the Austin ARM office.
<ogra> i'm starting on the image build script tomorrow
<ogra> should be ready on or probably before the weekend
<Martyn> so I was able to stop the boot, and append text to the kernel cmdline
<Martyn> awesome
<ogra> cool
<Martyn> yeah, it's nice to have a full kit now
<lool> Martyn: On my side I can tell you that http is broken in redboot, I suspect the network driver is shaky
<Martyn> lool : "shaky" is right
<Martyn> I just found a sllliiiight drawback to using the livecd/sd image for testing
<Martyn> no usb network modules :)
 * Martyn patiently waits for ogra's next drop :)
#ubuntu-arm 2009-03-19
<joshzhao> hi
<joshzhao> did ubuntu support s3c6410 ?
<Stskeeps> think it's armv5 capable
<joshzhao> yes
<NCommander> whats the s3c6410
<lool> joshzhao: You need to build your own kernel and any integration bits, but the userland should work, it's ARM11
<lool> NCommander: 10:11 < lool> NCommander: What are you looking into ATM?  Could you take that?
<lool> 10:12 < lool> NCommander: Also, kexec-tools was finally added to P-a-s, do you  think you could try it out?  it built on armel
<lool> NCommander: "that" being d-i
<NCommander> Been working on that already
 * NCommander learns how d-i goes together, but I'm making no headway on ARM
<NCommander> The last kernel upload made my board completely unreliable, and with it getting files at the speed of dial up ....
<NCommander> Same thing goes for kexec (that being said, I used the 2.0.0 release of kexec-tools on Babbage, and got nothing, so unless we're carrying patches ...)
<lool> NCommander: Please try the ubuntu kernels
<lool> NCommander: If there are bugs, file them
<lool> NCommander: Perhaps compare the exact same scenario in qemu/i386 and qemu/armel?
<NCommander> lool, it doesn't work in qemu/armel with our kernel as of the last time I tried it, I'm building a new qemu/armel image now so I can work on d-i, I'll test it once it finishes installing.
<lool> NCommander: Where's the bug report?
<lool> NCommander: the same test case passes on i386?
<NCommander> lool, I dunno if I filed a bug on this in Ubuntu, I did bring it upstream; no ping reply.
<joshzhao> i don't know what kind of Ubuntu Kernel tree  support 6410?
<joshzhao> s3c6410 is based on arm11
<joshzhao> samsung
<lool> NCommander: Are you waiting for me to ask you to file one or will you file one now?  :-)
<NCommander> lool, I'll file once I rerun the tests, filing bugs based on old data is a bad thing.
<joshzhao> lool: do you know what kind of Ubuntu Kernel tree  support 6410?
<lool> joshzhao: No
<lool> joshzhao: The Ubuntu kernel tree is close to the upstream one
<joshzhao> thanks lool
<mcasadevall> lool, if you have a few minutes, would you like to process one of the outstanding MIRs on RedBoot or ecosconfig?
<lool> mcasadevall: I'm queueing it up, but don't consider it assigned to me yet; I'm afraid I have a bunch of urgent stuff which is landing on my plate these days
<mcasadevall> lool, no problem.
<ogra> amitk, meh, FTBFS on imx51
<ogra>   Building modules, stage 2.
<ogra>   MODPOST 739 modules
<ogra> ERROR: "cpufreq_gov_performance" [arch/arm/plat-mxc/cpufreq.ko] undefined!
<ogra> ERROR: "get_cpu_wp" [arch/arm/plat-mxc/cpufreq.ko] undefined!
<ogra> ERROR: "dvfs_core_is_active" [arch/arm/plat-mxc/cpufreq.ko] undefined!
<ogra> ERROR: "cpu_wp_nr" [arch/arm/plat-mxc/cpufreq.ko] undefined!
<ogra> make[3]: *** [__modpost] Error 1
<ogra> make[2]: *** [modules] Error 2
<ogra> make[1]: *** [sub-make] Error 2
<ogra> amitk, throw cpufreq out, it has no use on the babbage anyway
<lool> It looks like you need to turn on these configs for the imx51 cpufreq backends
<lool> Hmm they are
<ogra> waht for ?
<amitk> ogra: I know, working on it
<ogra> ah, good
<ogra> intresting that it didnt fail in the PPA build
<amitk> ogra: could you test -11.35 (FINAL). It has AA and aufs, cpufreq solved. This might be our last chance before beta to fix this issue.
<ogra> amitk, after the meeting
<amitk> ogra: sure
<ogra> (i'll try to do i aside the meeting if really urgent though)
<amitk> naah.. I still have to work on the d-i bits. So anytime in the next 2-3hrs is good
<ogra> oh, wait, my inner clock is off one hour
<ogra> i can do it now
<amitk> did we change time?
<ogra> no, its 12 UTC
 * ogra smiles, a working NIC makes everything so much easier
<ogra> no more plugging around of USB keys to transfer kernels and initramfs
<amitk> ogra: make sure you get this http://people.ubuntu.com/~amitk/linux-image-FINAL-2.6.28-11-imx51_2.6.28-11.35_armel.deb
<ogra> yes, thats what i just installed and copied to my desktop
<ogra> now i'm doing a dist-upgrade to get new procps etc ... then i'll reboot and xmodem the kernel and initramfs over
<lool> ogra or amitk: I need /proc/cpuinfo on babbage with CONFIG_NEON=y (probably on the kernels you're running) and with the NEON hwacps merged in 2.6.28-10.33
<ogra> amitk, AA oops :(
<amitk> ogra: that is underinvestigation. just disable in on the cmdline
<ogra> same
<ogra> apparmor.enable=0 ... still oopses
<ogra> grmbl
<ogra> that costed me my working setup
 * ogra needs to rebot after upgrade ... 
<ogra> *reboot
<amitk> ogra: are you capturing the oops?
<lool> Would really appreciate a /proc/cpuinfo
 * ogra cant give a /proc/cpuinfo without getting into the system
<ogra> amitk, one sec
<amitk> lool: I'll have to build a new kernel with NEON enabled again
<lool> Is there a working babbage kernel I can run right now which has NEON support?
<lool> is the ubuntu one working for instance?
<amitk> lool: try the original ubuntu one, or one from http://people.ubuntu.com/~amitk/
<ogra> amitk, http://paste.ubuntu.com/133579/
<lool> Will either boot without initramfs?
<ogra> __aa_find_profile it seems
<amitk> ogra: same oops
<ogra> lool, yes, but you need rootdelay
<ogra> and no uuid root= line
<amitk> ogra: I'm compiling another one with AA turned off by default
<ogra> thanks
<amitk> ogra: same 'FINAL' .deb with AA compiled in but turned off by default
<amitk> back from lunch
 * NCommander sighs
<NCommander> THere is a max initrd size it seems on the Babbage
<NCommander> or something crazy ...
<ogra> how big did you b'koat yours ?
<ogra> *bloat
<ogra> up to 4.5M worked fine here
<NCommander> 2.5MB, I'm getting incomplete write, which suggests its too large
<ogra> funny
<ogra> i'm using a 4.2M one atm
<ogra> and had a 4.5 one before
<NCommander> ogra, its I'm an idiot problem :-)
<ogra> amitk, hmm, lost all my input capabilities again with the latest build
<ogra> amitk, did you remover the compiled in usb host drivers again ?
<ogra> *remove
<ogra> amitk, hrm, and i get compcache by default
<ogra> amitk, additionally the rest of the usb stack doesnt get loaded either
<ogra> amitk, and i dont see an indication of a kernel event happening
<ogra> aha, loading ehci-hcd helps
<amitk> ogra: I haven't touched anything else, you can check the config file
<ogra> weird
<ogra> my rootfs doesnt mount, ehci-hcd should be compiled in
<ogra> there is no trace of usb-storage in my initramfs
<amitk> ogra: it is
<ogra> (initramfs) ls /lib/modules/2.6.28-11-imx51/kernel/drivers/usb/
<ogra> host
<ogra> (initramfs) ls /lib/modules/2.6.28-11-imx51/kernel/drivers/usb/host/
<ogra> ehci-hcd.ko
<ogra> thats all i have
<ogra> (initramfs) uname -a
<ogra> Linux (none) 2.6.28-11-imx51 #35 Thu Mar 19 12:38:40 EET 2009 armv7l unknown
 * amitk checks again
<amitk> ogra: shoot me, you are right. EHCI_HCD is a module
<ogra> (initramfs) cat conf/initramfs.conf |grep MODULES
<ogra> # MODULES: [ most | netboot | dep | list ]
<ogra> MODULES=most
<ogra> so usb-storage should be there actually
<ogra> hmm
<amitk> ogra: storage is compiled in, so is USB_HID (for keyboard), but i left EHCI as a module for some reason
<ogra> ah
<ogra> that expleins it
<ogra> *explains
<amitk> that config file is swimming in front of me now
<ogra> ok
<ogra> i dont get why it uses compcache though
<amitk> ogra: because it is a module
<amitk> do you want it removed?
<ogra> it should only be included if there are less than 256M ram
<ogra> no, keep it
<ogra> but the script shouldnt fire
<ogra> (initramfs) cat /proc/meminfo
<ogra> MemTotal:         482808 kB
<ogra> there is definately more than 256M
<amitk> It is only a module
<ogra> argh
<ogra> TOTAL_RAM=$( grep MemTotal /proc/meminfo |tr -d ': [A-Z][a-z]')
<ogra> # Do not use compcache on the liveCD if we have more than 512M
<ogra> if [ "${BOOT}" = "casper" ]; then
<ogra>     if [ "${TOTAL_RAM}" -gt 524288 ]; then
<ogra>         exit 0
<ogra>     fi
<ogra> fi
<ogra> thats bad
<amitk> hehe
<ogra> i mean it works, but its pointless to have on babbage
<lool> The distro kernel doesn't boot for me
<lool> Uncompressing Linux.............................................................
<lool> And nothing more
<ogra> amitk, oh, does compcache get autoloaded if its there ? (it should never load alone)
<lool> Can someone hand me a recent kernel build with the NEON hwcaps patch?
<ogra> http://people.ubuntu.com/~amitk/linux-image-NO-AA-AUFS-USB-COMPILED-2.6.28-10-imx51_2.6.28-10.32_armel.deb not sure about neon
<ogra> but thats definately a working one
<lool> Thanks
<amitk> lool: grab the .deb from my p.u.c and grep the config.
<lool> amitk: It's not a config
<amitk> lool: you want the patch AND the CONFIG_NEON configured in, right?
<lool> amitk: Correct
<lool> But CONFIG_NEON has been set since forever
 * ogra wonders how long forever is for an unfinished kernel :)
<ogra> if [ "${BOOT}" = "casper" ]; then
<ogra>     if [ "${TOTAL_RAM}" -gt 524288 ]; then
<ogra>         exit 0
<ogra>     fi
<ogra> fi
<ogra> modprobe -q --ignore-install compcache compcache_size_kbytes="$(($(sed -nre 's/^MemTotal:\s*([0-9]+) kB$/\1/p' /proc/meminfo) * 25 / 100))"
<ogra> ARGH
<ogra> so if i boot with boot=casper and the system has 512M it will exit ... if the system has no 512M *and* i dont boot with casper compcache will load in *any* case
<ogra> thats so wrong ...
<ogra> i guess that needs an else condition ...
<ogra> oh, my, what was i smoking when i wrote that code
 * ogra takes a break ... thats so embrassing
<amitk> good stuff? :)
<amitk> ogra: new 'FINAL' uploaded. Hopefully the real FINAL :-/
<lool> The above kernel doesn't work for me either
<lool> Does it need an initramfs to output anything?
<lool> GRR
<lool> screen doesn't like too long commands
<lool> Ok, the kernel loaded over ymodem at least says "done, booting the kernel." but nothing more
<lool> ogra: is there serial console in the kernel you mentionned as working?
<lool> ogra: I definitely get zero output from the kernel with the .deb you pointed me at, only up to "done, booting the kernel.", even with console=ttymxc0,115200 console=tty0 on serial and VGA output
<lool> And the same thing with the FINAL .deb above
<lool> I'm booting with RedBoot> exec -c "console=ttymxc0,115200 console=tty0 root=/dev/mmcblk0p2 ro debug noinitrd rootdelay=2"
<lool> I confirmed that the way I upload kernels works as if I reload zImage_DVI it works
<lool> BTW I'm now updating the SD card directly
<lool> With dd and fis
<lool> amitk: Can you confirm the above kernels will work *without* initrd?
<amitk> lool: dunno. I have an initramfs
<lool> amitk: Could you show me fis list and/or a boot log so that I can use the proper fis create command here?
<FlimFlamMan> hello.  does anyone know when we might see usable Ubuntu netbooks on ARM?
<lool> I also need the cmdline with initramfs, so far I only have without
<lool> FlimFlamMan: No final date yet
<FlimFlamMan> lool: thanks.  what's the best place to keep track of how things are progressing, and what the shape of the final product will be?  will the "experience" basically be the same as on x86?
<lool> FlimFlamMan: The images Ubuntu will release for arm devices match images which exist for i386 already
<lool> FlimFlamMan: Following Ubuntu news channels should be enough to get the news
<FlimFlamMan> lool: Thanks for the information.  (I'm trying to judge whether i should hold off on a netbook purchase or buy an interim unit.)
<ogra> lool, yes, works fine for me
<lool> ogra: without initrd?
<lool> ogra: I'm using dpkg -x, replacing the kernel with the file in boot/vmlinuz-foo exactly in the same way as zImage_DVI, and it doesn't boot; while zImage_DVI works
<lool> I'm really confused
<ogra> i use dpkg -x on my laptop, boot into redboot serial, do xmodem, load the kernel and run a similar exec line to yours
<lool> ogra: what exact line are you currently running?
<ogra> might it be the dd/fis combo you use ?
<lool> it could be
<lool> I'm not using the default sizes for the fis partitions
<ogra> currently i'm using the lates kernel *with* initramfs ...
<ogra> (initramfs) cat /proc/cmdline
<ogra> console=ttymxc0,115200 root=UUID=ae90832f-ba0d-4164-b710-0402041ab8ed
<lool> ogra: Ah *with* initramfs
<ogra> right
<lool> I suspect that's the problem
<ogra> but it works fine without initramfs using yours
<ogra> no
<amitk> ogra: I put the new kernel on p.u.c
<ogra> amitk, thanks, trying
<ogra> lool, drop the "noinitrd"
<ogra> and the debug
<lool> amitk: http://people.ubuntu.com/~amitk/linux-image-FINAL-2.6.28-11-imx51_2.6.28-11.35_armel.deb ?
<amitk> yes
<ogra> exec -c "console=ttymxc0,115200 console=tty0 root=/dev/mmcblk0p2 rootdelay=2" should work
<ogra> (for me exec -c "console=ttymxc0,115200 console=tty0 root=/dev/sdb1 rootdelay=2" definately does if amitk doesnt play with USB modularization ;) )
<amitk> ogra: hopefully this time I don't have my head up you-know-where :)
<ogra> heh
<lool> ogra: no difference, it stops after "done, booting the kernel."
<ogra> strange
<ogra> works fine here
<lool> ogra: Can you show your fis commands?
<lool> Or your xmodem load rather
<lool> RedBoot says before booting:
<lool> entry=0x90008000, target=0x90008000
<lool> Using base address 0x00100000 and length 0x002144c0
<ogra> load -m xmodem -b 0x100000 -r
<ogra> fis create kernel
<ogra> thats what o do
<ogra> RedBoot> e -r 0x1000000 -s 4020573 -c "console=ttymxc0,115200 console=tty1 root=UUID=ae90832f-ba0d-4164-b710-0402041ab8ed quiet"
<ogra> entry=0x90008000, target=0x90008000
<ogra> Using base address 0x00100000 and length 0x0021020c
<lool> ogra: Do you have fis list or boot output?
<ogra> RedBoot> fis list
<ogra> ... Read from 0x1fee0000-0x1feff000 at 0x00040000: .
<ogra> Name              FLASH addr  Mem addr    Length      Entry point
<ogra> RedBoot           0x00000000  0x00000000  0x00040000  0x00000000
<ogra> FIS directory     0x00040000  0x00040000  0x0001F000  0x00000000
<ogra> RedBoot config    0x0005F000  0x0005F000  0x00001000  0x00000000
<ogra> initramfs         0x00060000  0x01000000  0x00400000  0x01000000
<ogra> kernel            0x00460000  0x00100000  0x00220000  0x00100000
<ogra> RedBoot>
<lool> ogra: and fis list -d?
<ogra> RedBoot> fis list -d
<ogra> ... Read from 0x1fee0000-0x1feff000 at 0x00040000: .
<ogra> Name              FLASH addr  Mem addr    Datalen     Entry point
<ogra> RedBoot           0x00000000  0x00000000  0x00000000  0x00000000
<ogra> FIS directory     0x00040000  0x00040000  0x00000000  0x00000000
<ogra> RedBoot config    0x0005F000  0x0005F000  0x00000000  0x00000000
<ogra> initramfs         0x00060000  0x01000000  0x003D595D  0x01000000
<ogra> kernel            0x00460000  0x00100000  0x0021020C  0x00100000
<lool> My datalen is 0x002144C0
<ogra> lool, i'm about to xmodem again, if you need anything else, say it now :)
<lool> ogra: I don't, unless you can be tempted to try my way of updating with fis
<ogra> i do, but only after i have a working initramfs again
<ogra> which takes a bit
<lool> ogra: How do you create the initramfs?  by installing the package?
<ogra> right
<lool> ogra: Hwo do you load it?
<ogra> installing the package and scp'ing to my laptop
<ogra> then i reboot and xmodem it over serial
<lool> load -m xmodem... wihch args
<ogra> load -m xmodem -b 0x1000000 -r
<ogra> fis create initramfs
<ogra> load -m xmodem -b 0x100000 -r
<ogra> fis create kernel
<ogra> exec -r 0x1000000 -s *size* -c *command line*
<ogra> where *size* is the output of ls -l
<ogra> for the initramfs file
<ogra> sillyness of the week, its not in hex
<ogra> while everything else is
<lool> I really don't get why it doesn't work for me
<ogra> try serial
<lool> ogra: Can you show me the messages before loading linux on the next boot?
<lool> ogra: I did
<ogra> check if that changes it
<ogra> i will
<lool> Will try serial again
<ogra> xmodem running now ... takes a while
<ogra> lool, http://paste.ubuntu.com/133688/
<ogra> its intresting how noisy it is even though i use quiet
<amitk> ogra: no explosions yet?
<ogra> not yet and i was even brave and just re-used the old initramfs from the former build
<ogra> rolling a fresh one now to make sure
<lool> ogra: same thing with xmodem
<ogra> weird
<lool> http://paste.ubuntu.com/133690/
<lool> But without initramfs
<lool> It's depressing
<ogra> hmm, i'm not sure the -b 0x100000 is right without initramfs
<ogra> look on the wiki
<lool> It's the same I used in the past and that I use for zImage_DVI
<ogra> hmm
<lool> wiki says    RedBoot> load -m ymodem -b 0x01000000 -r though
<ogra> shouldnt differ
<ogra> oh, wait
<lool> 0x01000000 != 0x100000
<ogra> 0x01000000 is the address used for the initramfs
<ogra> which needs to be loaded first
<lool> ogra: Yes, but the wiki mentions that for "an image"
<lool> I think it's wrong though
<ogra> so its likely that 0x01000000 gets copied into ram first
<lool> Anyway, it works fine with other kernels with 0x100000 and you use 0x100000 for kernel as well
<lool> Oh I know
<ogra> yes
 * lool bangs head
<lool> PFF
<lool> ogra: RedBoot version
<lool> *again*
<ogra> oh
<ogra> indeed i use NCommanders
<lool> All makes sense now
<lool> ogra: You need 2.6.28 redboot for 2.6.28 kernel and I was running 2.6.26 with its redboot still
<ogra> indeed
<lool> Two times I kill almost a day because of redboot version
<ogra> you said zImage_DVI
 * ogra killed a day because he didnt have lrzsz installed on the host 
<ogra> *that* was silly
<ogra> having a wrong redboot version is rather in the middle of sillyness in taht light imho ... not on the edge
<amitk> ogra: you're not complaining yet. I am getting worried...
<ogra> amitk, xmodem*ing initramfs atm
<ogra> let me reboot
<ogra> and then hammer the system a bit
<ogra> amitk, cross your fingers, booting now
 * amitk crosses fingers, hands, legs
<ogra> boot looks fine for a start
<ogra> gdm is up ...
<ogra> oh, usb errors in demsg
<ogra> *dmesg
<ogra> [42949494.010000] usb-storage: -- transfer complete
<ogra> [42949494.010000] usb-storage: Bulk command transfer result=0
<ogra> [42949494.010000] usb-storage: usb_stor_bulk_transfer_sglist: xfer 4096 bytes, 1 entries
<ogra> [42949494.010000] usb-storage: Status code 0; transferred 4096/4096
<ogra> [42949494.010000] usb-storage: -- transfer complete
<ogra> [42949494.010000] usb-storage: Bulk data transfer result 0x0
<ogra> [42949494.010000] usb-storage: Attempting to get CSW...
<ogra> [42949494.010000] usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
<ogra> [42949494.010000] usb-storage: Status code 0; transferred 13/13
<ogra> [42949494.010000] usb-storage: -- transfer complete
<ogra> [42949494.010000] usb-storage: Bulk status result = 0
<ogra> [42949494.010000] usb-storage: Bulk Status S 0x53425355 T 0x176e R 0 Stat 0x0
<ogra> [42949494.010000] usb-storage: scsi cmd done, result=0x0
<ogra> [42949494.010000] usb-storage: *** thread sleeping.
<ogra> over and over
<amitk> sounds like issues with their usb driver
<ogra> sounds like NCommanders issue
<amitk> mcasadevall: could you file a bug regarding your usb errors and tag it arm?
<amitk> ogra: does it prevent us from going further?
<ogra> let me see if it survives
<mcasadevall> amitk, sure, I think its a issue with my network adapter, since the USB storage seems to be okish
<ogra> i seem to be able to run a dist-upgrade getting 30M
<ogra> tail -f /var/log/messages doesnt show any probs atm
<ogra> hmm, now i see a bunch of usb-storage related messages
<giedz> hi...what is default window manager in ubuntu-arm port?
<ogra> giedz, any WM you like ... the architecture has noting to do with the CPU
<ogra> s/architecture/desktop/
<giedz> ok but is there any prefered?
<ogra> amitk, i see a ton of messages, but the package installation seems to work regardless
<ogra> amitk, will capture it for you once the dist-upgrade finished
<Martyn> afternoon ogra
<ogra> hey Martyn
<Martyn> I'm going to have to wait for your drop :)  I have a usb network adapter, but no way to use it until there are some kernel modules to load.  *chuckle*
<ogra> Martyn, http://people.ubuntu.com/~amitk/linux-image-FINAL-2.6.28-11-imx51_2.6.28-11.35_armel.deb
<ogra> that seems to be relatively good (just testing it here)
<ogra> ARGH
 * ogra wasnt aware DPMS works on babbage ... 
<ogra> i just thought my X crashed
<ogra> :P
<Martyn> Heh
<Martyn> DPMS works great in babbage
<Martyn> I've come to a blank console :)
<ogra> apparently
<Martyn> Now .. if we could only coax DVI to work :)
<ogra> not without a public driver
<ogra>  * Starting AppArmor
<ogra>  * Loading AppArmor module...
<ogra>    ...fail!
<ogra> pffft
<amitk> good
<ogra> the exclamation mark is really overreaction
 * ogra grabs the source and adds ...fail! (omg, OMG !!!!) to make it look more scary :P
<ogra> amitk, still not died, but /var/log/messages looks really worrying
<ogra> amitk, http://paste.ubuntu.com/133715/
<ogra> amitk, and /var/log/messages grew from 10 to 408k since i started the dist-upgrade, its completely filled with these messages
<amitk> ogra: I'm not too worried. It seems to be restricted to their storage driver. Fixable at a later date.
<ogra> apart from the fact that we will try to do installs to a USB device with beta i tend to agree
<lool> ogra: So yeah, it was definitely redboot and only that
<lool> I'm booting into my system just fine now
<ogra> cool
<lool> With VGA and all
<ogra> i just had a reboot notification after dist-upgrade :)
<ogra> so that works as well :)
<ogra> do you have a binary for fis ?
<ogra> so i can try to update my SD from the running system
<Martyn> ogra : I've got errors loading the modules, I'm afraid
<Martyn> ogra : 'invalid module format'
<lool> ogra: Sure
<lool> ogra: I'm mostly running it from my desktop though
<ogra> then your initramfs isnt in sync with your kernel
<lool> ogra: Let me write a flash-kernel alike script
<ogra> lool, oh, so no armel build ?
<Martyn> oh snap
<lool> ogra: I have one as well, but am not using it much now
<Martyn> sure, that makes sense
<lool> ogra: http://people.ubuntu.com/~lool/fis-armel
<lool> ogra: I updated redboot and kernel with fis on my desktop to boot into 2.6.28
<lool> Works fine
<ogra> but no initramfs yet, right ?
<lool> No
<lool> ogra: Needed a working system first
<lool> ogra: But that's *easy*  ;-)
<ogra> indeed, like me
<amitk> ogra: would making the various filesystems (ext2, 3, fat, vfat) as modules cause your problems?
<lool> ogra: Will write a flash-kernel alike script now
<lool> Unless you like to
<amitk> ogra: from perspective of updating an image
<ogra> amitk, once lool has the script ready he just talks about it wonmt
<ogra> lool, no, feel free
 * amitk will leave them compiled-in for a little more then
<ogra> i'll go on poking on my image creation tool
<lool> amitk: Why make them modules?
<ogra> amitk, though arent ext2/3 in the normal ubuntu kernels as well now ?
<lool> amitk: it's going ot be harder to boot without initramfs, and I don't think it's what we do on i386
<ogra> i thought Keybuk had pulled them in for boot speedup
<lool> Yes
<ogra> right, our kernel should be as close to the distro kernel as possible
<ogra> oh "system has a crash report detected" ...
<ogra> seems apport works too
<ogra> lool, do you also have the prob that the vga picture is slightly shifted to the top on the screen ?
<ogra> it swallows the upper third of the top panel here and i cant get it moved down
<lool> ogra: My LCD autoadjust
<lool> ogra: I'm running console ATM
<ogra> (under X)
<ogra> ah
<ogra> console is fine here
<Martyn> ogra : Are you running from flash, or USB?
<Martyn> SD or USB I should say...
<ogra> its just the desktop ... about 5-6px shifted to the top
<ogra> Martyn, usb atm
<lool> console is fine here too
<lool> I'm using SD
<ogra> both should work fine
<ogra> mcasadevall, so you just copied the iso to a USB key ?
<mcasadevall> ogra, pretty much. cdrom-detector didn't find it, but I manually mounted it
<ogra> what means "pretty much" ?
<mcasadevall> But its stuck ATM ... I dunno, I think the USB stack on my board leaves something to be desired w.r.t. to stability
<ogra> mount usb key, loop mount iso ... cp iso/* usb-key/ ??
<ogra> or what exactly did you do ?
<mcasadevall> No, I did that
<mcasadevall> But once in the installer environment
<mcasadevall> mount /dev/sda1 /cdrom
<mcasadevall> "Load Installer Compontents from CD"
<mcasadevall>    â This partitioner doesn't have information about the default type of   â
<mcasadevall>   ââ the partition tables on your architecture.  Please send an e-mail     â
<mcasadevall>   ââ message to debian-boot@lists.debian.org with information.             â
<mcasadevall> heh :-)
<mcasadevall> so far so good
<ogra> how did you get *in the installer environment*
<ogra> would be nice to have an alternate build you can just dd to SD
<ogra> i.e. with the right boot mechanism in place
<mcasadevall> ogra, oh, loaded the RAMdisk from RedBoot
<ogra> right
<ogra> thats what i mean, we should have an alternate image that has redboot, kernel and initramfs ready to dd it to SD
<mcasadevall> That's the idea
<mcasadevall> Its easy to do extactly that.
<ogra> so you just need to grab the iso/img file
<mcasadevall> But I wanted to see if the damn thing would work :-)
<mcasadevall> partman is going to need some work
<ogra> talk to cjwatson for that
<ogra> we'll likely need that for ubiquity too
<mcasadevall> damn it
<mcasadevall> "Failed to determine toe codename of the release"
<mcasadevall> So there are a few bugs to work out.
<mcasadevall> Actually
<mcasadevall> We got an anonyingly large issue
<mcasadevall> "Unknown armel subarchitecture: unknown"
<mcasadevall> Obviously thats something in the filesystem MIA
<mcasadevall> ogra, so libdebian-installer requires re-education :-)
<ogra> right the subarch thing is somethng i talked with colin about before but didnt file a bug yet and didnt approach him further about
<amitk> ogra: btw, are you using aufs now or unionfs?
<ogra> amitk, heh, neither, i'll test that soon
<ogra> my usb disk is ext3
<Martyn> ogra : Ah!  So you did a full install...
<ogra> (sorry, i'm in a short 1:1 meeting atm)
<Martyn> I'm building a rootfs right now
<Martyn> ogra : no worries.
<ogra> Martyn, right i built a rootfs using my script and untarred it to a usb HD
<Martyn> lool : Do you have a matching initrd to go with that kernel?
<ogra> and use an SD to boot that
<Martyn> I'm doing much the same, but using a usb enclosure with a 7200 rpm drive.
<ogra> me too
<ogra> :)
<lool> Martyn: will soon
<ogra> a kernel compile takes less than 1h with all modules :)
<ogra> on that fast disk
<Martyn> *nod*
<Martyn> I tried a 10k RPM drive, but the enclosure was just too frigging loud
<Martyn> It sounded like a small airplane about to take off
<ogra> heh
<Martyn> So I switch it out for a WD eco-drive/green drive.   1Tb, 7200rpm, 32mb cache
<Martyn> most of the time it sits idle, and that's perfect
<ogra> heh, i have the same setup, but a maxctor drive
<ogra> *maxtor
<Martyn> ogra : Hey, I just rebuilt the initrd, and still have the module format error.   *grump*
<ogra> did you transfer it to the SD ?
<Martyn> yep
<ogra> weird
<Martyn> Can I borrow yours and compare?
<Martyn> I must be doing something wrong
 * ogra looks for an envelope to send his
<ogra> :P
<Martyn> *groan*
<ogra> oh, you mean the initramfs
<Martyn> No, not the SD .. the initramfs
<ogra> i thought my SD
<Martyn> yep :)
<Martyn> and if I wanted to borrow your sd, all you'd have to do is dd of=myfile anyway :)
<mcasadevall> ogra, so I'm pushing my branch to LP now, and I'll have to start looking at libdebian-installer ;.;
<Martyn> mcasadevall : It doesn't fail gracefully eh?   unknown subarchitecture causes a crit fail?
<ogra> mcasadevall, make sure do coordinate with #ubuntu-installer
<mcasadevall> ogra, I am. I'm popping back and forth between the two channels.
<ogra> Martyn, http://people.ubuntu.com/~ogra/arm/babbage/initrd.img-2.6.28-11-imx51 and http://people.ubuntu.com/~ogra/arm/babbage/vmlinuz-2.6.28-11-imx51
 * ogra goes for a break
<Martyn> ogra : Got 'em
<ogra> amitk, aufs looks ok so far, i need to wait for tomorrows build to actually test it since i need the updated procps in the squashfs
<amitk> ogra: ok. I've pushed the changes to git and build-tested. rtg has done the same. So we might have a good kernel tomorrow.
<ogra> yay
<ogra> and with the fixed procps even a live image that can be used
<amitk> ogra: is imx51 live image created automatically now?
<ogra> not yet, no
<ogra> still some missing bits and pieces, i have the skeleton work done to rolla partitioned image and copy the livefs in
<ogra> tomorrow evening i sould have a working script
<ogra> creating one manually on top of my old image is easy though
<ogra> just copy the latest livecd image content into the second partition, pull vmlinuz and initramfs from http://people.ubuntu.com/~ogra/arm/babbage/ and replace them via serial
<amitk> ogra: would be nice to have an installable image
<amitk> eventually
<ogra> yeah, indeed
<ogra> that might only happen post beta though
<ogra> we dont know how ubiquity behaves yet
<ogra> and its a bit tricky since you will need an usb SD cardreader to install to, or we need to trash the install media
<Martyn> even if we don't have an installer, the rootfs builder provides a system that is just about the same when finished
<Martyn> So short term, you end up with a working desktop
<Martyn> (well, working-ish)
<ogra> indeed, but release target is an installable image
<ogra> preferably a live image
<Martyn> abolutely!
<Martyn> I'll take what I can get though.
<Martyn> Thank you for the initrd + kernel .. that helped a lot
<ogra> great
<lool> root@babbage:~# flash-kernel
<lool> Flashing kernel... done.
<lool> Flashing initramfs... done.
<lool> Ok, system still boots without initramfs
<lool> Now let's see with a proper boot script
<Martyn> lool : Did you just compile in all the drivers needed to get to console?
<lool> Martyn: I used the .debs provided above
<Martyn> mm
<lool> ogra: What do you put on your initrd aware command line?
<lool> exec line
<lool> I mean in the -c part
<lool> Ah wait, you mentionned cmdline
<lool> 15:52 < ogra> console=ttymxc0,115200  root=UUID=ae90832f-ba0d-4164-b710-0402041ab8ed
<lool> nothing
<ogra> e -r 0x1000000 -s 3927720 -c "console=ttymxc0,115200 console=tty1 boot=casper LIVEMEDIA=/dev/mmcblk0p1"
<lool> RedBoot> fis load initrd
<ogra> for the live image
<lool> ... Read from 0x1fee0000-0x1feff000 at 0x00040000: .
<lool> Not a loadable image - try using -b ADDRESS option
<lool> Hmm
<Martyn> fis load initramfs
<lool> ogra: did you manage to put it in fis?
<lool> Martyn: it is called initrd
<lool> in fis list
<Martyn> ah
<lool> Martyn: Probably I used wrong params, happy to hear what I should use
<lool> RedBoot> fis list
<lool> Name              FLASH addr  Mem addr    Length      Entry point
<lool> initrd            0x00460000  0xFFFFFFFF  0x00940000  0x00100000
<lool> RedBoot> fis list -d
<lool> Name              FLASH addr  Mem addr    Datalen     Entry point
<lool> initrd            0x00460000  0xFFFFFFFF  0x002A8EE7  0x00100000
<ogra> lool, do you use 0x1000000 as base address for it when dumping it into place ?
<lool> ogra: Ah no, I see what's wrong now
<lool> mem addr and entry point are reversed
<lool> I should have entry point == 0xffffff and not mem addr
<ogra> yeah
<ogra> initramfs         0x00060000  0x01000000  0x00400000  0x01000000
<ogra> thats what i have
<Martyn> what's the RedBoot command to load in something from serial, so you can flash it?
<ogra> load -m xmodem -b 0x1000000 -r
<ogra> fis create initramfs
<lool> Unfortunately, I can't get the ram address / load address from the fis command
<ogra> load -m xmodem -b 0x100000 -r
<lool> I have hardcoded it for now
<lool> Need to extend the command
<ogra> fis create kernel
<lool> Ok, fis load initrd works now
<Martyn> ah! xmodem :)
<Martyn> thanks
<lool> Now let's get the initrd to be picked up
<ogra> thats tricky
<ogra> since you need the size in the exec cmd
<ogra> so with each initramfs update we have toi touch the cmdline
<lool> ogra: Well I think we shouldn't need the size in the exec command
<lool> I'd rather *not* touch the cmdline that'd be awful   :-/
<ogra> you have to
<ogra> it wont boot without
<lool> ogra: my thecus doesn't need that and uses redboot
<ogra> we can use padding and fill up initrd with zeroes
<ogra> nopt the FSL redboot
<lool> I can do that
<lool> (padding)
<ogra> with padding the size can always be the sanme and we can use a fixed parameter in exec
<lool> ogra: even with padding, it doesn't set the address on the cmdline in the exec command
<lool> exec -c "console=ttyS0,115200 root=/dev/ram0 initrd=0xa0f00000,42M mem"
<lool> is all there is
<lool> Sorry, that's cut
<lool> exec -c "console=ttyS0,115200 root=/dev/ram0 initrd=0xa0f00000,42M mem=128M@0xa0000000"
<lool> That's a full line from the boot_script_data
<ogra> right, but with debian kernel and initramfs
<lool> Well with any
 * ogra tries to boot without -s parameter
<ogra> [42949379.640000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
<ogra> nope
<lool> ogra: It worked better for me
<lool> ogra: I can actually boot with exec -r 0x1000000 -c ... but it prints an error during boot and ignores initramfs
<ogra> heh
<lool> let me switch console to serial to copy paste it
<lool> RAMDISK: Compressed image found at block 0
<lool> RAMDISK: incomplete write (-28 != 32768) 4194304
<ogra> right
<Martyn> oop
<Martyn> that's bad
<ogra> thats what you get if exec doesnt get the size handed over
<lool> You think that's solved by padding?
<ogra> padding to 5000000
<ogra> and using exec -r 0x1000000 -s 5000000
<ogra> i *assume* that fixes it
<Martyn> well, at least then the boot script will be consistent
<Martyn> I'll try it.
<lool> ogra: I'd liket to avoid the size part
<ogra> yu wont
<Martyn> I'm uploading a ramdisk now, so it's just a little extra work to overlay the initrd onto a blank file made with dd if=/dev/zero of=initrd.template bs=1k count=5000
<ogra> else we need to fix the redboot we have now
<lool> According to the redboot manual, -s is mandatory
<Martyn> I wish the RedBoot supported zmodem.  (I switched to ymodem)
<lool> Too bad, I wish redboot would be clever just like for fis create after a load
<Martyn> what happens if you lie to redboot?
<Martyn> just tell it -s is 5000000
<Martyn> even if the ramdisk is smaller...
<ogra> right and pad
<Martyn> without padding
<Martyn> all it will do is load garbage bytes
<ogra> oh, that *might* work
 * ogra tries
<Martyn> <-- lazy
 * Martyn so badly wants to try to bump the serial port up to 230k ... it takes forever to load things at 115k
<ogra> [42949378.620000] RAMDISK: Compressed image found at block 0
<ogra> [42949378.900000] RAMDISK: incomplete write (-28 != 32768) 4194304
<ogra> :(
<ogra> i guess we need the padding
<ogra> blocksize seems to be 32768
<ogra> so 524288 should be a proper number for padding
<ogra> (16 blocks)
<Martyn> is it really that bad to have to put in the length of the image when doing fis create?
<ogra> fis create can take a lenght ?
<ogra> oh, right
<ogra> does that make -s not mandatory anymore ?
<Martyn> good question
<Martyn> I haven't tried it
<Martyn> it take ~4-5m for me to load the initrd via ymodem
<Martyn> I really wish the onboard NIC was working :)
<ogra> yeah
<Martyn> then I could load via network, and bim-boom-bam :)
<Martyn> almost done with the upload
<Martyn> fis create is broken
<Martyn> it's not setting the length, I think
 * ogra tries something
<Martyn> [42949379.550000] Please append a correct "root=" boot option; here are the available partitions:
<Martyn> [42949379.570000] b300         1956352 mmcblk0 driver: mmcblk
<Martyn> [42949379.580000]   b301          714892 mmcblk0p1
<Martyn> heh, so much for mounting a root filesystem from the mmc
<ogra> RedBoot> fis create initramfs
<ogra> ... Read from 0x1fee0000-0x1feff000 at 0x00040000: .
<ogra> ... Read from 0x1fee0000-0x1feff000 at 0x00040000: .
<ogra> Invalid FLASH image size/length combination
<ogra> so much for padded initramfs
 * ogra tries a smaller one
<Martyn> btw .. I booted just fine now
<Martyn> i'm stuck in the initramfs
<Martyn> but I did get a boot :)
<ogra> with the padded intiramfs ?
<Martyn> no padding
<ogra> but ?
<ogra> what did you do ?
<Martyn> oh, nm
<Martyn> I forgot to write the fconfig
<lool> So I tried with padding and failed
<Martyn> it reverted to using your commandline
<ogra> me too
<lool> But hex addresses are support for -s just fine
<ogra> how big did you make it ?
<lool> I checked the source code and -s is required
<lool> ogra: 0x00940000
<ogra> 4980736 bytes
<ogra> is what i'm trying atm
<Martyn> okay, so after the upload, every time, you have to check the size of the initrd then
<ogra> using the pad script from d-i
<lool> ogra: I used the same padding as for N2100
<ogra> Martyn, right, and thats what we try to get around atm
<lool> Now searching for kernel stuff
<ogra> i tried 5013504 before but seems redboot finds that to big
<Martyn> [42949379.550000] Please append a correct "root=" boot option; here are the available partitions:
<Martyn> [42949379.570000] b300         1956352 mmcblk0 driver: mmcblk
<Martyn> [42949379.580000]   b301          714892 mmcblk0p1
<lool> Oh perhaps my ramdisk is too big
<Martyn> oops, wrong one
<Martyn> [42949378.130000] RAMDISK: Compressed image found at block 0
<Martyn> [42949378.180000] RAMDISK: ran out of compressed data
<Martyn> [42949378.190000] invalid compressed format (err=1)
<ogra> Martyn, right, thats what you get if you give a to big size
<Martyn> crap
<ogra> (bigger than the actual initramfs)
<lool> I'm trying to locate the ramdisk decompression code, the ATAG parsing one can't help us
<Martyn> The size I gave was only 0x003e000
<lool> init/do_mounts_rd.c
<ogra> so we're attacking from two sides now :)
<lool> So >-------printk(KERN_ERR "RAMDISK: incomplete write (%d != %d) %ld\n",
<lool> >-------       written, outcnt, bytes_out);
<lool>     written = sys_write(crd_outfd, window, outcnt);
<lool> => -28 is an error
<ogra> yes
<lool> ENOSPC
<lool> window = kmalloc(WSIZE, GFP_KERNEL);
<ogra> RedBoot> fis create initramfs
<ogra> ... Read from 0x1fee0000-0x1feff000 at 0x00040000: .
<ogra> ... Read from 0x1fee0000-0x1feff000 at 0x00040000: .
<ogra> Invalid FLASH image size/length combination
<ogra> GRRR !
<Martyn> I got the same
<lool> WSIZE is 0x8000
<lool> out_fd = sys_open("/dev/ram", O_RDWR, 0);
<lool> Eh PPC and S390 have a spinner when loading the ramdisk
<Martyn> yep
<Martyn> it's just so unfair :)
<Martyn> I say we make a cooler, better progress loading bar, and show 'em
<Martyn> -snicker-
<Martyn> ( We hacked the cobalt kernels, back in 2.4, to output to a parallel LCD panel, and show a graphical loading bar .. it was silly as all hell )
<ogra> lool, do we really want to get stuck on that now ?
<Martyn> ogra : no :)
<ogra> lets just rewrite fconfig
<Martyn> -laugh-
<ogra> i know you would like to get around it, but thats the way that waorks atm
<ogra> *works
<Martyn> ogra : It's not really worth it, is it?  We're not going to be using redboot forever, right?
<Martyn> just until u-boot gets ported and mature.
<ogra> hopefully not ...
<Martyn> ugh
<ogra> we have to run fconfig anyway to get the UUID in
<Martyn> I can't get the initrd to load
<Martyn> I tried specifying the -precise- -s length
<Martyn> okay, something's funny
<ogra> make sure to load it first
<Martyn> I did
<Martyn> loads fine
<Martyn> but when the kernel boots, it's not there
<Martyn> or at least, I'm getting a vfs error
<ogra> whats your current exec line ?
<Martyn> e -r 0x1000000 -s 4001525 -c "console=ttymxc0,115200 console=tty1 root=/dev/sda1 text"
<ogra> 4001525 ?
<ogra> right, thats proper
<ogra> root=/dev/sda1 might be wrong though
<ogra> try sdb1
<Martyn> what would be taking up /dev/sda?  the media card is mmcblk0p1
<ogra> and eventually use the UUID
<ogra> nothing, sdX are no guaranteed names anymore
<ogra> use UUID
<ogra> root=UUID=<your uuid>
<Martyn> Which means I'll need to write a disklabel with the UUID  :)
<ogra> no
<ogra> you have a uuid already
<ogra> its created if you format the partition
<ogra> at the initramfs prompt: ls -l /dev/disk/by-uuid/
<lool> ogra: Updating the config is really painful
<ogra> lool, we have to do it anyway
<lool> ogra: Why so?
<Martyn> got it
<lool> mxc_ipu mxc_ipu: VSyncPre occurred before DI1 disable
<ogra> to get the device uuid into the append string after install
<ogra> lool, thats your display being switched on and off
<lool> ogra: indeed
<ogra> i would propose we concentrate on a better way to write fconfig
<lool> ogra: Ok; it's enough for me for today though
<ogra> instead of trying to hack the current working boot methor
<ogra> *d
<ogra> lool, same here
<lool> ogra: I don't think it's hack if we get it to work sanely
<lool> I consider changing the size on each upgrade dangerous
<ogra> i doubt we can
<ogra> we will only end up with a hardcoded size or something i suspect
<lool> I don't think it's as bad as it could kill the flash, but it's risky
<ogra> which isnt better
<lool> ogra: i don't mind a hardcoded size
<lool> It's not pretty, but it's not risky on upgrades
<ogra> i would neither if it was easy ... i.e. through padding
<ogra> but that apparently doesnt work
<ogra> so we would have to dive deeply into redboot
<ogra> and hack it up
<ogra> i honestly prefer to rather find a sane way to update fconfig
<lool> ogra: I dived into redboot *already*
<ogra> ok
<lool> We can't do anything with stock redboot
<lool> Unless we change it
<lool> I'm looking at the kernel now
<lool> My hope is that I can find a magic byte which stops the decompression
<Martyn> -s is very, very nonoptional
<lool> Another thing which would be worth trying is whether we can limit the initrd size at another level
<Martyn> booted to console, went with busybox rather than ubuntu rootfs
<lool> Martyn: I checked the redboot sources and it's not optional
<ogra> we could fill up with zeros *before* compressing
<lool> packages/hal/arm/arch/current/src/redboot_linux_exec.c
<lool> search for ramdisk_size
<Martyn> ogra : They would be compressed away
<lool> And that's why I can assure you it supports hex, and hex worked for me
<ogra> lool, nonoptional ==  not optional ;)
<Martyn> hex works for me just fine as well
<ogra> sure
<ogra> but what does hex gain us here
<Martyn> nothing really
<ogra> right
<lool> ogra: I know, I said it earlier as well; I'm just repeating it because you seem to be doing the same research
<ogra> no, i researched padding
<Martyn> I'm surprised, though, that it doesn't simply scan or set the length of the ramdisk image somewhere
<Martyn> rather than forcing the user to set it manually.  There must be a reason...
<lool> ogra: hex> just replying to the fact that it was said to be broken, and it's not
<Martyn> fis has all the smarts to load it, and stuff the value somewhere...
<ogra> the thing is, if we fill the cramfs with zeros before zipping it it might probably work
<lool> Martyn: Yes, that's why I checked as well; but it has not
<ogra> not sure, but possible
<lool> We could implement it, but I don't want to rely on our redboot to be present
<lool> ogra: I did that already
<Martyn> Well, then we have to write the config each time, and there's no getting around it
<ogra> lool, padding during compression ?
<lool> ogra: I created a 0x00940000 file with intiramfs contents + zeroes, checksummed that
<Martyn> every time the initrd and kernels are updated, the fconfig boot script likewise has to be updated
<Martyn> UNLESS
<Martyn> you want to do the two-kernel tango like they do in beowulf
<Martyn> load a kernel, that chainloads the new kernel and initrd from disk
<lool> ogra: Ah no, I didn't understand what you meant; I don't see how you'll get exactly the good size though
<ogra> lool, right, but you likely padded zeros to the end of the already compressed file
<ogra> lots of math ...
<ogra> you only need to know the two values ... before and after
<ogra> then pad cramfs to a certain size ... after gzip you should have the right final size
<lool> I think it might be enough to pass the initrd size to the kernel to stop decompression at EOG
<lool> EOF
<ogra> in the -c command you mean ?
<lool> Yes
<ogra> but that still means we need to run fconfig
<lool> No, I think it works with a zero padded initrd if we pass its size
<Martyn> I don't think you can get away from that one
<ogra> no matter where you have to add the exact size in exec ... you have to submit it
<lool> ogra: it's just a cut size
<lool> That's my N2100 exec line:
<lool> exec -c "root=/dev/ram0 rw rootfstype=ext2 initrd=0x01000000,10M noirqdebug mem=32M@0x00000000 console=ttyS0,115200n8" 0x01d00000
<lool> The 10M is just to stop the unzip I think
<ogra> right, but exec still doesnt know what to do
<lool> ?
<ogra> the -s tells it to load initramfs, no ?
<lool> Yes
<ogra> so how do you tell exec what to do ?
<lool> Oh I still need the -s for bababge
<lool> I was pointing at initrd=0x01000000,10M
<ogra> right
<Martyn> ogra, lool's command line works!
<Martyn> I just did it
<Martyn> no -f, no -s
<Martyn> just -c
<lool> Err 0x01d00000 is in the initrd
<lool> How come
<lool> Martyn: With the 0x01d00000?
<Martyn> no, without it
<lool> Ok
<Martyn> my line was ->
<lool> Martyn: For me it works, but the initrd isn't run
<Martyn> e -c "console=ttymxc0,115200 initrd=0x1000000,10M console=tty1 root=/dev/sdb1 text"
<Martyn> hmmm
<Martyn> [    0.000000] Memory policy: ECC disabled, Data cache writeback
<Martyn> [    0.000000] INITRD: 0x01000000+0x00a00000 extends beyond physical memory - disabling initrd
<Martyn> Interesting, I get the same message
<lool> I think you need to pass mem
<Martyn> what's the appended 0x01d00000?
<lool> It's the kernel entry point for N2100
<lool> 0x00a00000 us lel start
<lool> is mem start
<Martyn> setting the mem= parameter had no impact
<lool> It hangs for me if I set mem
<ogra> here too
<ogra> it doesnt uncompress
<Martyn> I did mem=512M, and skipped the @
<ogra> though i assume we overwrite something
<Martyn> is initrd=0x01000000 REALLY what we mean?
<Martyn> that's where fis put it on the flash, but that's not where it got reloaded in ram, right?
<ogra> right
<lool> In the case of my thecus it matches
<ogra> anyway, i'm really exhausted
<Martyn> me too
<lool> You can't set mem alone without setting the start address
<lool>         start = memparse(*p, p);
<lool>         if (**p == ',') {
<lool>                 size = memparse((*p) + 1, p);
<lool>                 phys_initrd_start = start;
<lool>                 phys_initrd_size = size;
<Martyn> lool : Um, I do that all the time on the x86 platform...
<Martyn> heh
<ogra> but not to define initrd size
<lool> Martyn: that's arm specific though
<lool> linux/arch/arm/mm/init.c
<Martyn> http://clug.open2space.com/node/10
<Martyn> oops, sorry
 * ogra calls it a day
<ogra> my brain hurts and i dont see us getting anywhere by poking in the dark
<Martyn> nope.  I'll look at redboot tonight, now that I've unpacked the fsl-redboot source
 * ogra thinks its better to attack that after a relaxing night of sleep
<Martyn> I'm a few hours behind you, so I'm fresher
<Martyn> it's 15:30 here
<ogra> note that we ise redboot-mxc from the archive
<ogra> *use
<Martyn> oh!
<Martyn> is it downloadable?
<ogra> (which actually is the same)
<ogra> indeed
<Martyn> URI?
<ogra> its in universe atm
<ogra> apt-get source redboot-mxc
<Martyn> ports, universe?
<Martyn> gotcha
<ogra> err
<ogra> redboot-imx
<ogra> sorry, to tired
<Martyn> no worries
<Martyn> downloading, and I'll take a read in a bit
<ogra> you need to build it on the babbage though
<Martyn> I have a working-ish boot now, I can probably do it
<Martyn> but really, I should start poking through the source and understanding the exec code
<Martyn> and the load code
 * ogra wonders what packages/redboot/current/src/fs/e2fs.c is :P
<lool> ogra: I told you rebdoot supported filesystems!  :)
<ogra> lets look at that tomorrow :)
<lool> ogra: Well I don't think our version has it
<lool> Unless it's a new drop, could be
<lool> Ah ours has e2fs but not fat
<ogra> right
 * lool &
<ogra> i just pulled michales packge and found packages/redboot/current/src/fs/e2fs.c
<ogra> sleep tight lool
 * ogra is off as well now ... finally
<lool> http://people.ubuntu.com/~lool/flash-kernel
<lool> has the padding ATM
<ogra> bah, you break my naming scheme
<ogra> error "Cannot find FIS partition 'initrd'"
<lool> ogra: what did you use?
<lool> We could support multiple names easily in this place
#ubuntu-arm 2009-03-20
<d1b> hi i'm trying to work out what arm v i have and if it is supported by ubuntu.
<d1b> what's the best way to work it out
<Martyn> well
<Martyn> What hardware are you running?
<Martyn> If you know that, you're halfway there.
<Martyn> ports has an entire tree compiled for v5, and that runs on just about everything
<d1b> damn he left
<d1b> its an arm9
<lool> d1b: You'll need to provide your kernel, but you can use the userspace apps
<d1b> lool: oh ? won't i hit problems ?
<lool> d1b: problems can never happen
<d1b> its running debian lenny atm. not sure what optimisations / compile options are vs ubuntus (armel) (+ its running a 2.6.28.8 kernel)
<lool> d1b: lenny is armv4t, jaunty is armv5t
<ogra> lool, my initramfs fis partition is called "initramfs" indeed :)
<lool> ogra: Could you try the new version of the script I pushed to p.u.c?
<lool> It should fallback on "initramfs"
<ogra> bug #328167
<ubot4> Launchpad bug 328167 in gnome-keyring "gnome-keyring-daemon eating 100% CPU at login in Jaunty" [High,Triaged] https://launchpad.net/bugs/328167
<Martyn> morning
<Martyn> ogra : Awake?
<lool> Martyn: found the ramdisk issue this morning
<lool> kernel config was too small
<ogra> lool, so i create an image with dd
<ogra> run fdisk on it
<ogra> Disk ./imx51-armel.img: 0 MB, 0 bytes
<ogra> thats what i get from "p"
<ogra> though the image is 800M full of zeroes
<lool> ogra: Can you create an empty disk label on it though?
<lool> ogra: "o"
<ogra> You must set cylinders.
<ogra> You can do this from the extra functions menu.
<ogra> Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
<ogra> oh, wait
<lool> ogra: it works for me
<ogra> yeah
<ogra> Building a new DOS disklabel with disk identifier 0xfbc883b4
<lool> dd if=/dev/zero of=hda.img bs=1024 count=10240
<lool> fdisk -l ./hda.img
<ogra> i looked to far down
<lool> Disque ./hda.img: 0 Mo, 0 octets
<lool> 255 tÃªtes, 63 secteurs/piste, 0 cylindres
<lool> UnitÃ©s = cylindres de 16065 * 512 = 8225280 octets
<ogra> <lool> Disque ./hda.img: 0 Mo, 0 octets
<ogra> <lool> 255 tÃªtes, 63 secteurs/piste, 0 cylindres
<lool> that's ok
<ogra> well, i somehow need to compute the free space at the beginning
<lool> ogra: You will miss the total cyl count but you can compute it
<lool> It's always going to be 255/63 anyway
<ogra> right
<ogra> but fdisk doesnt know the total size
<lool> ogra: Ups, even when setting the cylinder in the advanced settings, it wasn't picked up
<lool> That's a problem
<ogra> right
<ogra> i wanted to use kpartx since thats been recommended by the server team
<ogra> but that requires loop devices
<ogra> and i dont want to run as root
<ogra> so cant mount loop
<ogra> fdisk would likely work as well with loop and offsets
<lool> ogra: So no choice but parted I think
<ogra> i did that before
<lool> Yes, I think fdisk on loop would work
<lool> It's how I built my image actually
<lool> And I used kpartx for the parts
<ogra> right, but i want to get around using root
<lool> ogra: understood which is why I say parted
<lool> albeit I can't figure whether it requires root or not
<ogra> yeah
<ogra> well, gparted does (works fine btw)
<ogra> not sure about parted
<lool> ogra: it works here
<lool> parted  ./hda.img  mklabel msdos
<lool> some warnings, but seems ok
<lool> parted  ./hda.img  print
<lool> Disque /home/lool/fdisk/hda.img : 103MB
<lool> Taille des secteurs (logique/physique) : 512o/512o
<lool> Table de partitions : msdos
<ogra> yep
<lool> You want parted -s all the time
<lool> -m is nice too, but hard to read :)
<ogra> Disk identifier: 0x000e11c2
<ogra>             Device Boot      Start         End      Blocks   Id  System
<ogra> ./imx51-armel.img1             321       12800      798720    b  W95 FAT32
<lool> then do some mkpart
<ogra> ok, gparted works for partitioning, but formatting fails
<lool> you don't need that, do you?
<ogra> i suspect i'll see the same with parted
<ogra> sure i do
<lool> Why so?
<ogra> i need to copy the livefs content to the partition
<lool> ogra: Hmm I see; I guess you just need to copy the recipe for usb keys from cdimage
<ogra> so preferably i want a vfat partion so that i can mcopy from one image to another
<ogra> no, the usb keys dont use partitioning
<lool> Yes
<lool> ogra: they use a vfat partition
<ogra> well, not more than a single partition
<lool> ogra: You can tell parted to create a part without fs, that's mkpart above
<ogra> accessing the second partition is the prob
<lool> Just compute its offset?
<ogra> creating partitions is easy
<ogra> anyway, let me poke a bit
<lool> ogra: you could also try parted 'cp'
<ogra> if parted could see the second partition
<ogra> which i doubt it can for a non block device
 * ogra goes to play with it
<lool> I don't think cp will help
<lool> It can't read from non-partitioned devices
<lool> or files
<ogra> ok, that looks good
<Martyn> good morning all
<amitk> morning
<Martyn> Ogra, lool, did you manage to find out what fs'es are supported/supportable in Redboot?
<ogra> nope
 * ogra is working on general image creation atm
<Martyn> Okay.
<ogra> sigh, and parted needs a size for the partition ending
<Martyn> I had some strange lockups last night, running the -11 kernel you made
<Martyn> no friendly oops'es either, the board just locks up and even trying to break in with sysreq doesn't do diddly.
<lool> Martyn: in theory perhaps e2fs, but we lack time to look into this for this cycle, it needs redboot expertise and someone looking into that should start by forward porting to latest redboot IMO
<ogra> so now how do i create the redboot part
<lool> ogra: With type non-FS data
<lool> ogra: size of your choice to hold all we need
<lool> For instance 32 M
<ogra> no, fond something better :)
<ogra> fis init actually works fine
<lool> I don't think there's any assumption on the end of it; redboot will just create default partitions for rb, fis dir, and perhaps kernel by default
<amitk> ogra: i'll probably leave 'early' today. Let me know on irc if the increased RAMDISK size solves your problem.
<ogra> no, you have to giove size in bytes
<ogra> amitk, i had no problem
<ogra> we just discovered its limited
<lool> ogra: I'm saying 32M as a guidance
<ogra> lool, well, my spare space is 20M atm
<lool> ogra: you'll use something better for what?  non-FS data?
<lool> ogra: spare on what?
<ogra> for fis init i gave 10M
<ogra> spare space on the image
<ogra> the first partition starts at 20M
<ogra> the space before that is yet empty
<ogra> fis -s 10000000 -d ./imx51-armel.img init should then create a ~10M fis setup where i can copy redboot in
<lool> I thought you were asking about the msdos partition size
<ogra> no
<lool> I would use round hexa numbers in fis values
<lool> Because flash data needs to be aligned on flash boundaries
<ogra> i'm just playing atm
<lool> So we might run into problems if you don't make that a multiple of 0x20000
<ogra> and the fis help says it needs to be the value in bytes
<lool> It takes hex in the other places
<ogra> if it works as i think it does, the only open is fconfig
<ogra>   -s size      specify size of directory in bytes
<lool>         size = str_to_int_maybe_hex(argv[i]);
<lool> So it takes hex
<lool> See, source beats --help  :-P
<ogra> bah
<lool> I think it's "in bytes" by opposition to "sectors"; it didn't say "in decimal"
<ogra> like in offset you mean
<lool> ogra: for fconfig, just copy static data from you SD for now
<ogra> well, first i need to see if what i expect actually does what i expect
<lool> ogra: there are two approaches, either you prepare the redboot stuff in its file, then use the size of this file as a basis to create the msdos part; or you create the msdos part and create the fis straight into that
<lool> But then you need an offset
<ogra> / Parse a string containing a number.  If it starts with 0x, parse the rest as hex.
<ogra> / !!! NOTE: also parses octal constants that start with '0' !!!
<ogra> static unsigned int str_to_int_maybe_hex(const char* s)
<ogra> btw :)
<lool> Yeah?
<ogra> it only converts if needed, else it will assume bytes
<ogra> in dec
<lool> Well, yes, that's kind of obvious
<ogra> ah, damned
<ogra> fis wipes the partition table in the image
<ogra> so i need to do the fis stuff before using parted
<lool> ogra: it does not
<lool> ogra: It's because you didn't use an offset...
<ogra> i dont use an offset when creating SD cards with the fsl tool either
<lool> offset is 0x40000
<lool> ogra: Different tools?
<ogra> not really, since the same thing is happening
<ogra> you have to create the partition after dd'ing the babbage_init.bin
<ogra> else the same happens
<ogra> just forgot about it
<lool> Yes, but for different reasons
<lool> babbage_init.bin contains a partition table
<lool> anyway, just pass correct offset and size and it will work, even on the resulting SD image
<Martyn> besides, the partition table is wholly in the first sector
<ogra> 0xA00000 for 10M, right ?
<lool> A00000 yes
<Martyn> In fact, you -should- reserve the first 63 bytes
<Martyn> er, 32 bytes
<lool> The network driver in 2.6.28 is really a pain
<lool> local scp: linux-image-2.6.28-11-imx51_2.6.28-11.36_arme  27% 2208KB   5.5KB/s - stalled -
<ogra> yeah, use a USB NIC
<ogra> doesnt your CB come with one ?
<lool> It does, good idea
<ogra> hrm, but looking at my SD redboot starts at 0x00000000 with a lenght of 0x00040000
<ogra> how do i still keep my part table with that ?
<lool> ogra: it's lying
<lool> ogra: it starts at 0x400
<ogra> ah, k
<lool> ogra: Note that "fis init" + romupdate from redboot might give you a redboot on 0x0 which doesn't boot
<lool> Never tried it, but I wouldn't be surprized
<ogra> well, i dont have a redboot yet
<ogra> only an empty fis table
<lool> ogra: I'm just commenting on how we reached the point where the fis list says 0x0 for redboot offset
<ogra> yup
<lool> I think it correctly reflects 0x400 with images created with the fsl tool, but not after fis init
<ogra> dd if=<redboot.bin> of=<image> bs=1024 seek=1 should now get me a booting image, right ?
<lool> Yes, I think that's correct
<lool> make sure you use the non-padded redboot
<lool> it's also best if you fis create redboot
<lool> with -c that .bin
<lool> to reserve the space and make fis list happy
<ogra> do you know the offsets/sizes from the top of your head ?
<lool> RedBoot           0x00000000  0x00000000  0x00040000  0x00000000
<lool> FIS directory     0x00080000  0x00080000  0x0001F000  0x00000000
<lool> RedBoot config    0x0009F000  0x0009F000  0x00001000  0x00000000
<ogra> -o 0x400 ?
<lool> careful it's not -o for the fis offset; only for the fis dir
<ogra> oh, right
<lool> e.g. for the kernel I'm using:
<lool> sudo "$FIS" -d "$SD_DEV" -o $FIS_OFFSET -s $FIS_SIZE create kernel -f 0x00060000 -l 0x00400000 -e 0x00100000 -r 0x00100000 -c "$KERNEL_IMG"
<lool> 0x00060000 is the offset of the kernel in flash
<lool> So you want 0x400 for redboot offset (-f) and 0x4000 for fis dir offset (-o)
<lool> The first three should remain constant
<ogra> i really think i like dd more :P
<ogra> i dont see the FSL tool do anything to the fis tables
<lool> usb 2-1.3: new high speed USB device using fsl-ehci and address 5
<lool> > I don't get any module loaded
<lool> ogra: You need *both* dd and fis
<ogra> lool, oh, old kernel i guess
<lool> Well from yesterday yes
<ogra> mcasadevall, is our redboot unpadded in the binary ?
<lool> I guess I'll take the SD card out and update the kernel manually, sigh  :-(
<mcasadevall> ogra, its unpadded, but I can dd if= it
<ogra> no, thats what i want, thanks
<ogra> i want my script to wget and dpkg -x our package
<lool> [42949379.640000] RAMDISK: Compressed image found at block 0
<lool> [42949380.210000] RAMDISK: incomplete write (-28 != 32768) 8388608
<ogra> ah, good
<ogra> amitk, ^^^
<lool> BTW that's with exec -s 0x00800000 -r 0x1000000 -c "console=ttymxc0,115200 root=/dev/mmcblk0p2 rootdelay=2 initrd=0x91000000,8M mem=200M@0x90000000 ro debug"
<amitk> hmm
<amitk> so much for leaving 'early'
<lool> also failed with exec -s 0x00600000 -r 0x1000000 -c "console=ttymxc0,115200 root=/dev/mm
<lool> cblk0p2 rootdelay=2 initrd=0x91000000,6M mem=200M@0x90000000 ro debug"
<lool> Probably it's an unpack sized issue
<lool> Same command without initrd and mem doesn't work either
<lool> I see the USB interface with the new kernel, but it doesn't manage to DHCP
<amitk> lool: that is an asix chip, right?
<lool> amitk: What the RAM?
<lool>  512 MB mDDR 4 banks (each bank is 128 MB)
<lool> Micron MT46H64M16LFCK-6LIT
<lool> Hynix H5MS1G62MFP-J3M
<amitk> lool: no, your usb interface
<lool> Oh, I don't know; it's the one I had with CB; it's a SMC
<lool> amitk: yes, asix is loaded
<lool> amitk: Ok, it was my bad: I was setting the mac address and that doesn't work
<lool> Without setting it it works
<lool> I tried padding to 0xff to no luck; I thought that would have worked  :-/
<ogra> hmm, dd if=<redboot.bin> of=<image> bs=1024 seek=1 trashes my part table
<ogra> mcasadevall, are you 100% positive our redboot is unpadded ?
<mcasadevall> ogra,I didn't pad it, but the build system might have
<lool> sudo dd if=mx51_babbage_redboot-no-padding.bin of="$SD_DEV" bs="1024" seek=1
<lool> that worked for me
<lool> With the 2.6.28 redboot from the wiki page
<ogra> right
<ogra> i suspect ours is padded
<lool> ogra: it seems so indeed
<lool> 00003e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
<lool> 00003f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
<lool> 0000400: 2806 f0af b100 0000 0000 0000 1404 f0af  (...............
<lool> 0000410: 0000 0000 1c04 f0af 0000 f0af e919 72b1  ..............r.
<ogra> meh
<lool> it clearly starts at 0x400; albeit I don't see why there are a couple of bytes at the beginning isntead of zeroes
<lool> ogra: Just skip=1 as well
<lool> dd if=<redboot.bin> of=<image> bs=1024 seek=1 skip=1
<ogra> yep. trying
<ogra> nope
<ogra> partition table is gone
<ogra> ours is also quite big compared to FSLs
<ogra> -rw-r--r-- 1 ogra ogra 161688 2009-01-23 20:54 /home/ogra/Desktop/arm/babbage/mx51_babbage_redboot.bin
<ogra> even with padding theirs is smaller
<ogra> -rwxr-xr-x 1 ogra ogra 172844 2009-03-20 18:14 redboot.bin
<lool> partition table *can't* be gone if you're skipping over it
<lool> Are you speaking of the fis directory or the msdos table?
<ogra> its trashed at least
<ogra> msdos table
<lool> with seek=1 it shouldn't be, it's in the first 1k
<ogra> yeah, thats strange
 * ogra wonders if the order matters, probably i should run fis init afterwards
<lool> HMm
<ogra> hmm, now i end up with 18M
<lool> No, fis init only overwrites the directory
<ogra> (visible space in gparted)
<lool>   int num_entries = size/sizeof(struct fis_image_desc);
<lool>   write_blank_entries(fd,num_entries);
<ogra> weird
<ogra> so after fis init i still see a proper part table in gparted on the image ...
<ogra> if i run the dd after fis init gparted only sees a 128M big empty space
<lool> Can I see your script?
<ogra> if i run it before it sees an 18M big empty space
<ogra> http://paste.ubuntu.com/134317/
<ogra> not very big yet
<lool> ogra: size=800 + bs=1M + count=size => size=800M bs=$size count=1
<lool> I hope that's not abusing too much  :-)
<ogra> do you think that helpos the particular prob ?
<ogra> *helps
<lool> No
<ogra> right :)
 * ogra changes 
<lool> I hope that doesn't use 800M of memory, but I don't think so
<lool> ogra: err revert that, sorry
 * lool whistles lalala
<ogra> heh
<lool> ogra: mktable?
<lool> parted -s $IMAGENAME mktable msdos
<lool> parted -s $IMAGENAME mklabel msdos
<ogra> yeah
<lool> I don't see that command in the parted doc
<lool> well man page
<ogra> creates the initial part table
<lool> and mklabel?
<lool> I think it's the same thing
<ogra> creates a dos label for the device
<ogra> oh, right
<lool>               mklabel label-type
<lool>                      Create  a  new disklabel (partition table) of label-type.
 * ogra drops mktable
<lool> ogra: fis offset is 0x4000 not 0x40000
<lool> # initialize redboot fis dir and create redboot partitions
<lool> fis -o 0x40000 -s 0x1200000 -d $IMAGENAME init
<lool> And size is way too large
<ogra> 18M
<ogra> i kept 20M spare space at the beginning
<lool> It's the size of the directory
<ogra> oh, not dir+contents ?
<lool> You should always always always call fis with the same fixed offset and size: offset of dir and size of dir
<lool> FIS_OFFSET=0x40000 FIS_SIZE=0x1F000
<ogra> you mean the same as flash-kernel will use ?
<ogra> ok
<lool> Uh there's is an inconsistency between my fis sizes
<ogra> right
<mcasadevall> We have a d-i port for imx51 that (mostly) works :-)
<ogra> 0x40000 not 0x4000
<lool> ogra: yes, sorry
<lool> ogra: and 0x80000 with the first redboot we had!
<lool> how stupid  :-(
<lool> mcasadevall: excellent news
<lool> mcasadevall: So netboot?
<mcasadevall> lool, netboot AND cdrom :-)
<lool> mcasadevall: How do you use the cdrom image?
<mcasadevall> lool, SD card with redboot+kernel+initramfs+rootfs
<mcasadevall> Install to USB stick
<mcasadevall> Or
<mcasadevall> SD card with the first three, and the alt CD on something else.
<lool> excellent
<mcasadevall> I need to talk to Steve and colin on how we're going to handle image creation
<lool> mcasadevall: So next step there is creating a SD card image with first three?
<mcasadevall> I could spin a handmade image like that if that's what you want
<ogra> great, i will try to write my script in a way that we can either build live or alternate from it
<lool> I don't think we want to create a CD sized image; a way to slash it into SD would be nice though
<mcasadevall> lool, I hven't tested the netinstall image though
<lool> mcasadevall: No, I think we will get it from ogra's script
<ogra> right
<lool> ogra: cool
<mcasadevall> The current kernel has quite a few annoyance w.r.t. to network performance
<mcasadevall> I'm going to say it probably works, but your millage may vary
<ogra> for the cdrom i only need to make the second part etx2 (symlinks in pool) and use an initramfs from d-i
<mcasadevall> lool, base-installer also has a nice set of patches to handle kernel installation, if the kernel post-install does the right thing, then touching d-i again is likely unnecessary :-)
 * lool calls it a day; I started at 7:30 and am tired
 * ogra will to that too soon
<lool> ogra: I suggest you put a cleanup handler instead of having rm -rf at various places
<ogra> lool, yeah, in the end
 * mcasadevall won't, the final battlestar galatica is on tonight
<ogra> its still a young script :)
<ogra> though i expect it to be able to run on chinstrap if we cant get build server approval in time :)
<ogra> avoiding root is really helpful ;)
<ogra> hmm, no matter what i do, the dd trashes my partitioning
<ogra> i'll try to unpad our redboot first tomorrow
<ogra> lets see if that changes anything
 * ogra calls it a day and goes relaxing
<Martyn> re
 * mcasadevall dances like a madman
#ubuntu-arm 2009-03-21
<lool> Ah good hwclock works
<ogra> lool, heh, found my mistake :P
 * ogra feels massively silly
<ogra> dd if=$BUILDDIR/redboot.bin of=$IMAGENAME bs=1024 seek=1 .... *replaces* the image with redboot instead of just writing it to the start of ut
<ogra> *it
<lool> ogra: Eh try with conv=notrunc
<lool> I'm so used to writing to block devices, I didn't of that either
<ogra> oh
 * ogra didnt think of *that* now ... :) 
<ogra> i just started to build the image in a staging manner
<ogra> appending each piece and in the end pad with zeros
<Martyn> morning ogra
<Martyn> Padding works?
<ogra> the prob is that the kernel and initramfs checksums dont match
<ogra> Martyn, other topic
<lool> ogra: I think conv=notrunc will be easier to maintain, but do as you prefer
<Martyn> ogra : Was a suitable solution determined for having to specify -s in RedBoot?
<ogra> no, i'll try with conv=notrunc, that might actually solve my checksum prob
<ogra> though i have to shuffle everything around in the script now
<ogra> Martyn, nope
<Martyn> ogra : Okay, so it's an inconvenience we'll have to live with, but only that.
<Martyn> Since it's easy to determine the size
<Martyn> I'm making some headway with RedBoot this morning.
<Martyn> Using the already ported code for hints on porting the current RedBoot
<ogra> lool, ok, i got fis, kernel and initramfs working on a partitioned image ... (can actually boot my USB disk after manual serial fconfig) ... tomorrow i'll care for copying the livefs in place ...
<Martyn> We'll have an installer!
<ogra> nah, just a liveimage that doesnt boot yet (without fconfig) ...
<ogra> but built by a script on an x86 machine ...
<ogra> and without being root
<ogra> we still need the fis utility packaged and a solution for the fconfig stuff
<ogra> *then* we can start thinking about the installer :)
<ogra> oh, crap, the livefs we build is an iso
 * ogra curses
<ogra> i was convinced we build vfat .img's
<ogra> that makes non-root building impossible ... gar
<Martyn> why?
<ogra> because i need to loop mount it
<Martyn> Oh for the sake of Demeter....
<Martyn> heh.
<Martyn> ogra : And this, THIS is why I like FuseFS so much
<ogra> i doubt we have fuse on the build servers
<ogra> oh, we do
<ogra> hmm
<ogra> well, something to look at tomorrow
<ogra> lool, hrm, no recent squashfs ... it stopped building on the 16th and we have no kernel in it apparently
<ogra> StevenK, when did you add kernel support to the live builds ?
<ogra> StevenK, was that after Mar. 16th ?
<ogra> anyway, 10h are enough for a sat. ... /me calls it a day
<Martyn> agreed!
<Martyn> Go give your wonderful girlfriend the time she deserves :)
<Martyn> This problem will be just as much here on Monday
#ubuntu-arm 2009-03-22
<kblin> hi folks
<Stskeeps> wello
<kblin> I don't seem to have ipv6 support in the 2.6.28-11-versatile kernel. is that expected?
<kblin> if so, what do I need to _get_ ipv6 support?
<lool> kblin: a) file a bug b) build your kernel
<Martyn> morning lool
<lool> hi Martyn
<Martyn> lool : I'm slowly gettting Redboot ext2/3 working
<Martyn> lool : slow more from it being a lazy Sunday than anything else...
<Martyn> I'm just puttering along
<lool> Nice
<lool> Happy to hear if you get it to work, unlikely that we change solution at this point though
<kblin> lool: is there any pointer for building my own kernel for the box? I assume a cross-compiler is the way to go here, but I never worked with one so far
<Martyn> lool : It's not _all_ about canonical, yanno :)
<Martyn> *chuckles*
<Martyn> I have certain goals to meet @work for the project we're on too :)
<kblin> huh? I've installed build-essential, but I don't seem to have a linker.. is there a special package I need to install?
<lool> kblin: http://www.hermann-uwe.de/blog/building-an-arm-cross-toolchain-with-binutils-gcc-newlib-and-gdb-from-source
<lool> kblin: We build natively
<kblin> lool: thanks, I'll look into that
<kblin> lool: isn't building natively a tad slow?
<snookie_> I can cross compile an app fine but when I cross compile a kernel driver, I'm getting errros:   arm-vfp-linux-gnu-gcc: M=/home/snookie/embedded/chubasco/drivers/gpio: No such file or directory
<snookie_> anyone know what I'm doing wrong?
<snookie_> in my make file, I specify arm-vfp-linux-gnu-gcc, am I supposed to use make?
#ubuntu-arm 2010-03-22
<lool> apw: Heya
<lool> apw: On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524893 the config change can actually be reverted; it didn't help and wasn't actually needed once the fix was found
<ubot4`> Launchpad bug 524893 in qemu-kvm (Ubuntu Lucid) (and 3 other projects) "versatile: Can't boot initramfses (affects: 1)" [Low,Fix released]
<lool> I also had in mind to kill the default cmdline from the config, it overrides the ATAG mem information and qemu-ssytem-arm uselessly defaults to 32MB of RAM
<lool> (that is, passing -m foo to qemu-system-arm isn't enough, one has to pass mem=foo too)
<persia> 32MB!!!!!
<lool> Yup
<lool> triggers d-i "Low mem mode"
<lool> persia: It's from the defconfig
<lool> it's an old board
<persia> right.
<lool> apw: sent to the list
<lool> persia: BTW did you get a chance to go over the /Ports page?
<lool> persia: I'd like to hook it up from the /Development page now
<persia> Unfortunately not.  It was top-of-my-list for Saturday, until something else intervened.  I'll look at it as soon as I've eaten.
<lool> Ok thanks
<nosse1> Are there any good reasons for me to up my host to Lucid to develop/build Luicid ARM targets (w/rootstock)?
<rcn-ee> nosse1, depends if you also want to test x86 lucid. ;) otherwise karmic works fine, just use the bzr trunk of rootstock
<nosse1> of course I want to test Lucid x86 as well... ;)
<nosse1> rcn-ee: rootstock is one, script right? Not spread across several files?
<rcn-ee> yeah, it's just a script that access qemu..
<nosse1> excellent. I think I got it then.
<nosse1> Now I'm this close to attempt to run Lucid on TI AM3517 Zoom eval kit
<rcn-ee> it should work as i run it on a varity of omap35x targets... just make sure you config meets these requirements http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head%3A/readme.txt
<nosse1> rcn-ee: Have you deployed Ubuntu on any omap35x targets for production environments, or just still development?
<rcn-ee> nah, i haven't pushed my customers off karmic yet, as lucid just hit beta-1 last week..
<rcn-ee> i have two internal development beagles running it 24/7 thou, testing different things..
<nosse1> Ush... ARM Lucid didn't work out-of the box... Well, I didn't really expect that either...
<ogra> works here :)
<nosse1> It boots the kernel, and head into NFS, but then it just sits there after "init: ureadahead main process (552) terminated with status 5"
<ogra> ah, NFS
<ogra> there might be mountall bugs with NFS, check launchpad
<nosse1> Are there any good tools for debugging nfs-links? i.e. smart cmd options for tcpdump
<nosse1> I'd like to see what specific files are being accessed
<ogra> well, try to reach your server from the busybox shell in your initramfs etc
<ogra> thats why ubuntu uses initramfs all over the place ... makes debugging so easy :)
<nosse1> hehe: That might just be it then. I tried without initramfs :o
<ogra> well, depending on your kernel it should work even without initramfs
<ogra> its years ago i used rootfs on NFS so i wont be a big help
<nosse1> Because you dont really need the initramfs if everything is build statically in the kernel, right. Theres nothing special the distro requires?
<ogra> there is
<ogra> lost of packages place stuff inside the initramfs in ubuntu
<ogra> *lots
<nosse1> How do you build one then?
<ogra> update-initramfs -c -k <your kernel version>
<ogra> on a running system
<nosse1> Thats assuming a running system, yes
<ogra> (prefix that with sudo)
<ogra> if you dont have a running system, take your sd make sure to have qemu-arm-static installed and run the command in a chroot on the SD
<ogra> (on your x86 system)
 * nosse1 noob, SD=?
<ogra> Sd card
<ogra> oh, you probably dont use one if you use NFS :)
<ogra> just chroot into your exported rootfs then
<nosse1> Ah. So thats how you run instead of NFS?
<ogra> using an SD card, yes
<nosse1> I recon, since you compile packages natively, moving files back and forth to x86 isn't made as often as you would on a purely crossed target
<nosse1> ..so a SD card is fine
<ogra> right, i usually only use x86 for bringup and building a booting image
<nosse1> i have to admit my other colleagues are sceptical to build the apps natively on a 500MHz ARM target
<ogra> well, if you use ubuntu as ubuntu developer you can just develop under x86 :)
<ogra> the packages are built automatically on all arches anyway
<nosse1> yes, I see both advantages and disadvantages of doing it like this
<ogra> it really depends *what* kind of app you buiuld natively though
<nosse1> I'm a little worried that vanilla ubuntu becomes too heavy for a small ARM target, yet it is nice to not have to worry about the system
<ogra> if its just a desktop app it surely is a lot easier to build it natively and have all dependencies already available
<ogra> well, define *small*
<nosse1> The other alternative is some kind of LFS in a cross build environment
<nosse1> Our product will have a sys-flash of 1G
<ogra> LFS cross building might gain you incompatible binaries
<ogra> 1G flash isnt enough for any of the ubuntu desktops
<ogra> not sure about LXDE but even if that would fit it wouldnt leave you much space for user data
<nosse1> Yes. Package and product upgrade feats of distro like Ubuntu is very tempting
<ogra> indeed
<nosse1> No desktop (sort of). The product will be a end-user product where the user shall not know that Ubuntu is running behind the curtain
<nosse1> But it will be a Qt app running either on X11 or directly to fbdev
<nosse1> Size isn't that critical (shoult fit into 1G), but startup-time into final application is far more critical.
<ogra> well, if you only compile your app, i would go with natively ...
<ogra> whats the desired time you have ?
<ogra> and with which bootloader ? :)
<nosse1> Q is then how much tweeking to Ubuntu is needed to make the app start fast enough
<nosse1> TI uses U-boot
<ogra> which is a fairly slow thing in itself
<nosse1> Lets say 10-30 secs is fine
<ogra> thats half of it for uboot
<nosse1> Uboot will be optimized in order to speed things up
<nosse1> thats the easy part
<ogra> if you only fire up your app 15sec should beeasily doable
<ogra> my laptop takes 8 from grub to gnome desktop atm ...
<nosse1> Ah, but it's a laptop.. What are we talking about on your ARM targets?
<ogra> and that starts a lot more stuff, even though its x86 and 4G RAM and a fast SSD, 15sec for u-boot-end to app-on-screen will be achievable
<ogra> ARM targets are depending on the disk you run your system off
<ogra> mainly
<ogra> ubuntu-netbook on a babbage board takes from 35 to 45sec
<ogra> (thats imx51 from USB key or USB attached SATA disk)
<ogra> though imx51 loses nearly no time to the bootloader ... (6-10sec)
<ogra> redboot is a lot faster than u-boot ... but a lot less flexible
<nosse1> BTW: Those ARM targets used in the Launchpad build farm, what kind of machine/specs are we talking about? Some of these compiles must take a while?
<ogra> (and very painful)
<ogra> the ARM buildds are all imx51 800MHz 512M machines
<nosse1> Yeah, I know. I've been working with imx35 previously and thus redboot
<ogra> with USB disks
<persia`> lool: Regarding Development/Ports : there's a lot of TODOs left: are you sure you want to strong-link it already?
<persia`> Also, there are N ways to set up schroots: I'm unsure I want to document all of the manual methods (and they're all painful).
<lool> persia`: We could hide them as comments
<persia`> Yeah, hiding them works.
<lool> persia`: Well, I'd like to document how you use sbuild for arm development
<persia`> I can document use easily.
<persia`> For creation, I can't recommend mk-sbuild enough.
<lool> persia`: hidden now
<lool> persia`: Oh ok, I thought you tested mk-sbuild successfully?
<persia`> Sorry: translation error.  I mean to say that not using mk-sbuild is so painful that there is no limit to the degree to which I will recommend it to any schroot/sbuild users
<lool> persia`: Do you consider the sbuild section good enough?
<persia`> Basically, one has to create the (directory, tarball, LV snapshot, etc.) manually, and then stick it somewhere, and then write the configuration manually.
<persia`> I'll add in some notes on usage with schroot and sbuild.
<lool> persia`: I'm not a regular sbuild user; I have it installed and now how it can overall work, albeit not the latest features thereof
<lool> persia`: Ok good
<lool> persia`: When you're done, just remove the commented-out TODO
<nosse1> Where does rootstock stage its files?
<nosse1> OK, sorry for my elementary questions: If I have a rootstock/qemu image either as .img or as tar.gz, how can I invoke qemu to boot from that image/root?
<nosse1> I.e. I need a kernel and I need to make the kernel load the root from the image, I presume
<ogra> nosse1, see the rootfs from scratch wikipage (from the channel topic)
<nosse1> ogra: embarrasing. Of course, thanks!
<persia`> lool: Sorry that took so long.  Use of schroot/sbuild documented : please take a look to make sure it makes sense to you.
<lool> persia`: Looks good
<persia`> lool: What I wonder is if we need to go to any more effort to make clear that these procedures (should) work for armel/powerpc/sparc
<persia`> (getting a little off-topic for this channel)
<persia`> I don't want to create the impression that one must use pbuilder for armel and sbuild for powerpc, nor the impression that this is armel only.
<lool> persia`: Let's hope that the people reading it are technical enough to understand that, and fix it if we discover it's a problem
<persia`> That sounds reasonable :)
<lool> I don't think it's off topic for this chan since we're trying to improve ports documentation as driven by the lack thereof for arm  ;-)
<persia`> heh
<persia`> Do you happen to know if qemu-system-ppc needs as many special arguments as qemu-system-arm ?
<lool> persia`: I happen not to know
 * persia` either
<persia`> Oh well, there's enough fast ppc HW out there that most folks use native anyway.
<lool> ISTR seeing people run qemu-system-ppc without any -M arg, but I don't know what kernel's we're building for
<lool> Wow powerpc has a vmlinux and armel a vmlinuz, how odd
<nosse1> ogra: Now this is interesting. Earlier this day I failed getting lucid to run on target. Kernel booted, but failed in userspace. When I now start qemu, I get the same failure
<ogra> nosse1, whats the failure ?
<nosse1> Hold on. I hoped I could get the console output with -nographic, but it only dumps the pre-linux bootloader
<persia`> nosse1: I often find "-monitor stdio" to be  useful argument when I'm having issues, as this lets me manipulate the session in the terminal whilst it executes in the SDL environment.
<nosse1> ogra: From the start of init, I see the following messages 1) modprobe: Could not load ...modules.dep  2) init: ureadahead main process (381) term. with status 5   3) mountall: Could not connect to Plymouth     4) Same as 1 again
<ogra> thats all fine
<ogra> nothing to worry about
<nosse1> Then nothing. After a while I get sda sense key errors in qemu
<ogra> thats something to worry about :)
<nosse1> This time I'm running from ext3 file-image
<ogra> how did you build your image ? just using rootstock --notarball ?
<nosse1> Yup
<ogra> and then the commandline from the wiki ?
<ogra> with the kernel from there ?
<nosse1> Hold on, I'm getting lots of errors on e2fsck of the image
<nosse1> yes
<ogra> i dont see that here
<ogra> what was the exact commandline you used with rootstock ?
<nosse1> Hoi.. Here I got a tracedump of something in the console
<nosse1> I used "sudo ./rootstock --imagesize 1G --seed ubuntu-minimal --dist lucid --notarball"
<ogra> ah
<ogra> well, that will fire up oem-config
<nosse1> rootstock is the patched one to be able to use my karmic against lucid
<ogra> which can take a few minutes to start
<lool> persia`: Apparently, one needs to pass -M prep to qemu-system-ppc, and one needs a BIOS which we lack in Ubuntu; see https://bugs.launchpad.net/ubuntu/+source/openbios-sparc/+bug/183495
<ubot4`> Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed]
<ogra> nosse1, if you want to prevent oem-config just use th e-l and -p options for rootstock
<ogra> *the -l
<lool> persia`: surprisingly, the two files mentionned by https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/60478 are around on my system
<ubot4`> Launchpad bug 60478 in qemu (Debian) (and 1 other project) "Missing files for qemu-system-ppc (dup-of: 183495)" [Unknown,Fix released]
<ubot4`> Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed]
<nosse1> ogra, thanks I'll try. My end objective is to get a working image for me to be able to use on target.
<persia`> lool: I have them both as well.
<ogra> nosse1, well, if you boot it on the target system, just wait a little longer, it will bring up oem-config after a while
<persia`> lool: I know far too much about the openhackware and openbiod-sparc issues.  They aren't fixable with current Soyuz.
<ogra> to configure user, language, keymap etc
<ogra> W: u-boot-omap3 source: quilt-build-dep-but-no-series-file
<persia`> lool: OK, so qemu-system-foo really only works for armel right now.  That makes it easy.  Thanks for checking.
<ogra> hmm, is that new ?
<persia`> ogra: No.
<ogra> i never needed debian/patches/series before
<nosse1> ogra, I have to admit I perhaps didn't wait long enough to determine whether the target was busy or dead.
<ogra> persia`, well, the complaint is
<persia`> quilt creates it automatically.
<persia`> No, it's been around since jaunty, at least.
<nosse1> ogra, but the output was the same on targes as on qemu
<ogra> weird, i never saw that before when building a package and picking quilt
<ogra> nosse1, on qemu it will take even longer until oem-config comes up
<persia`> You probably never didn't have a series file before.  Like I said, quilt does it automatically.
<persia`> ogra: I've found quilt incredibly easier to use since adding http://paste.ubuntu.com/399386/ as my ~/.quiltrc
<ogra> ah, thats nearly the same cjwatson gave me
<persia`> His was from /usr/share/doc/quit/README.source
<persia`> Which works exactly the same, only faster for 90% of cases.
<nosse1> The kernels you build for target, do you cross compile them or do you also do that natively?
<ogra> nosse1, see /topic :)
<persia`> nosse1: Everything is natively compiled.
<ogra> bah, sigh ... series needs to contain a comment
<persia`> No it doesn't.
<nosse1> What happens if I install gcc from my qemu. Will it be capable of generating code for real target?
<persia`> nosse1: As long as your target is compatible with the instruction set gcc is targeting, yes.
<ogra> persia`, diff.gz wont represent empty files
<ogra> so lintian still complains
<ogra> unless i add a comment or something
<persia`> ogra: series shouldn't be empty unless you have no patches, and if you have no patches, you shouldn't have a build-dep on quilt.
<ogra> persia`, i want the new packages i build to reflect a selection for the patchsystem
<ogra> so people touching the package know what to use
<ogra> ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_source.changes
<ogra> ogra@babbage2:~/u-boot-omap3-2010.3git20100315$
<ogra> there we go :)
<persia`> Just use Format: 3.0 (quilt) then.  No build depenency required.  No debian/rules magic.  Expresses the preference for quilt.
 * ogra builds a binary
<ogra> persia`, i wont revert what i did now :)
 * ogra has to get the thing done today 
<persia`> anyway, you're supposed to express that preference in debian/README.source
<persia`> Just ask first next time :p
<ogra> expressing that preference in README.source doesnt quiet down lintian
<ogra> i want the package to be ready so people can just drop in diffs
<ogra> as i do with i.e. dpatch
<ogra> and given that asac perfers quilt and i get heat from people that i use dpatch everywhere i thought i should start switching to quilt
<ogra> even though i dont like it
<ogra> in any case i want my packages to be ready for patching right away, without having to fiddle with build-deps
<persia`> Fair enough.  Next time you do a package, make me walk you through using format 3.0(quilt) so you have it easy.
<ogra> ok
<persia`> (which never requires build-dep on quilt and still uses quilt)
<ogra> ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_armel.deb
<ogra> W: u-boot-omap3: wrong-bug-number-in-closes l3:#XXXXXX
<ogra> PFFT !
<persia`> ogra: You want (LP: #...) anyway.  This is the pain of dh_make
<persia`> Don't forget to make it not Priority: extra too.
<ogra> i know, i just havent filed a bug yet
<ogra> err, what prio should it have ?
 * ogra always leaves it extra
<nosse1> Can I shutdown qemu/debian from the monitor gracefully? I notice the ext2 img is easily corrupted
<ogra> persia`, what but debootstrap uses the priority field anyway ?
<nosse1> errr  ubuntu NOT debian. Sorry.  (Don't throw any stones.)
<ogra> nosse1, we wouldnt exist without debian, why would we throw anything ? :)
<nosse1> :D
<persia`> ogra: Every package manager displays it
<ogra> nosse1, the karmic version used ext2 and i'm not sure you can do anything beyond "sudo halt" ... afaik the kernel wont power off the VM, you need to close it then
<ogra> persia`, so suggest a prio :)
<ogra> its a bootloader that only exists on arm and shouldnt be used anyway unless you build images
<persia`> ogra: "optional" is correct for nearly all new packages
<ogra> ok
<persia`> Wait.
<persia`> "shouldn't be used anyway unless you build images"?  Is it not useful for installed devices?
<nosse1> ogra, the login/pwd of my image doesnt work so I cannot login. And the image runs when using -snapshop. The kernel crashes without it
<ogra> persia`, well you can use it if you roll your own beagle images
<ogra> theoretically
<ogra> but for ubuntu installs we'll use flash-kernel anyway to write u-boot to NAND
 * nosse1 trying rootstock again
<ogra> so there is no real point in actually using it for anyone (while you *can* if you want to)
<ogra> persia`, main point of the package is to make d-i and live images using the u-boot-beagle.bin file from this package (along with the MLO file from the x-loader package thats already in the archive)
<persia`> ogra: OK. YOu have a special package where "extra" happens to be correct.  This is very rare :)
<ogra> ah
<ogra> persia`, you have to teach me one day how to make proper dh7 packages that can do multiple runs for different configs on the same source
<ogra> eventually i want the u-boot-omap3 package to support all omap targets but that needs several builds
<ogra> (with one binary for each target)
<persia`> ogra: That's going to take time, and is best done with physical presence I think.  That is the sort of thing where looking over a shoulder is useful.
<ogra> i know how to do it the old way but dh7 is rather blurry to me
<persia`> Yeah.  dh(1) is just as flexible as dh_*, but most folk get confused because of the CDBS-like features.
<ogra> yeah
<ogra> its not important now though ... rather a L+1 thing
<ogra> beagle only is sufficient atm
<ogra> but given the source can also build for zoom1/2 and EVM boards i'D like to sopport them one day
<nosse1> Must qemu be run as root?
<nosse1> According to e2fsck, the images produced by rootstock have fs-errors
<persia`> qemu definitely doesn't need to be run as root.
<rcn-ee> nosse1, that's pretty normal, just let it clean it up...
<rcn-ee> e2fsck is usually not happy with the time variances so it checks just in case..
<ogra> or use lucids rootstock (since you build minimal images anyway)
<nosse1> Yes, but it seems to be coinciding with crashes of apps inside qemu. I'm not sure, it just seems that way
<ogra> in lucid rootstock defaults to ext3
<nosse1> I'm getting inode count errors and such
<rcn-ee> nosse1, does it clear up on the next reboot?
<nosse1> Sometimes I get kernel crashes, sometimes stack dumps in the console and other times I get "I/O error, dev sda"
<nosse1> Using -snapshot seems to remedy all of these errors
<rcn-ee> sounds fun, which kernel you using?
<nosse1> vmlinuz-2.6.31-rc3versatile1-cortex-a8
<ogra> nosse1, thats definately not the one from the wiki
<ogra> (i asked you before if you use the one from the wiki)
<nosse1> Yes, you're right. I have no clue where this vmlinuz-2.6.31 came from. It was just lying in my dir.
<nosse1> But using the one from the wiki, I still have the sda I/O error issue
<ogra> heh
<rcn-ee> hey ogra, just catching up on the backlog, you guys really planning to put the kernel in nand?
<rcn-ee> (omap's)
<ogra> rcn-ee, likely, yes
<ogra> as long as kernel and initramfs actually fit
<rcn-ee> okay.. yeah they should... but as side note, the xm might come with no nand.. (to get 1Gb ram..)
<ogra> i need to do some measuring ... my last days were busy with packaging x-loader and u-boot and starting to design the live images
<ogra> from tomorrow on i'll start working on the flash-kernel changes we need and on the actual image builds
<ogra> we will definately flash x-loader and u-boot with the versions from the image during install
<ogra> i'm not 100% sure about kernel and initramfs yet
<ogra> (for now my focus is to have *something* ready by end of the week ... we'll be able to make changes to that before beta2)
<asac> ogra: use deb3
<ogra> asac, ??
<asac> err source format 3.0 ... that comes with great quilt integration
<ogra> asac, for my next packages i will ... to late now :)
<asac> you dont need to know how to use it in order to work with it
<ogra> thats evil !
<asac> ogra: if you used quilt we can just convert it easily
<rcn-ee> true.. ;)  btw, i got my iegp2 working over the weekend.. with 500.2  it'll need about 4-5 backports from 2.6.34-rc2 for dss2/ethernet.. ;)
<ogra> right
<asac> cool
<ogra> asac, i'm trying to use quilt by default now even though i hate it
<ogra> rcn-ee, do you know if iegp2 uses the same x-loader and u-boot ?
<nosse1> ogra, I still get I/O error on sda using qemu and this time the kernel from the wiki ( ;) )
<rcn-ee> it's different... ;)
<ogra> nosse1, sorry i have no idea whats going on there, does your user own the disk image ?
<ogra> (i.e. does he have write access to it)
<ogra> rcn-ee, sad
<nosse1> ogra, yes
 * ogra would love to have one generic omap image that works everywhere
<rcn-ee> It's using 1.4.2 x-loader, but i'm not sure if it's the same as beagle.. (it does use OneNAND Flash, so that's different..) the U-boot is 2009.08 and uses boot.ini scripts at boot. (instead of beagles boot.scr) same format thou..
<nosse1> I'll search around
<ogra> nosse1, worst case you could grab rootstock from lucid
<rcn-ee> but 720mhz & 512Mb ram, so it's going into my gcc farm after i get lucid booting.. ;)
<ogra> or just change ext2 to ext3 inside the rootstock script manually
<ogra> rcn-ee, hey, thats nearly as good as the babbage board :)
<ogra> you just need SATA ;)
<ogra> ok, my revC4 boots with x-loader and u-boot from the archive ...
<rcn-ee> yeap it is.. ;)  yeap no sata, but onboard wifi and bluetooth.. ;)
<ogra> time to call it a day ... i was up early
<ogra> wifi ++
<rcn-ee> sound cool, you have c4 usb patches right?
<ogra> i havent booted to a rootfs
<ogra> amitk would know if we have all patches
<rcn-ee> u-boot set's up the regulator for the ehci port on the c4, that's why i asked.. i don't think they are in u-boot mainline yet...
<ogra> rcn-ee, do you know if the board initalizes the framebuffer if you dont give any omapfb options on cmdline ?
<ogra> oh, i packaged u-boot-omap3 ;)
<rcn-ee> okay, that should work then..
<ogra> didnt touch mainline
<ogra> sarkomans tree
<rcn-ee> i was thinking that over the weekend..  it didn't in the past... and we've always defined it on the command line...
<nosse1> ogra, I'm using a rootstock patch which i got from asac. I needed it to be able to run qemu for a lucid target on a karmic (64-bit) machine
<rcn-ee> so i would say no...
<ogra> crap
<rcn-ee> there is a read edid script in angstrom.......
<ogra> thats really messy behavior ... it should jut read EDID
<ogra> yeah, that was dropped years ago from ubuntu
<ogra> doesnt help me if i need the value on cmdline
<ogra> the driver should just check the monitors capabilities and set the highest resolution by default
<rcn-ee> the other issue, the omapfb comand also allocates kernel memory too for the frame buffer...
<ogra> i wonder why that seems to be so hard
<rcn-ee> Well, there is a big limitation on the screen size... (hardware pixel clock)
<ogra> that should also have a default value
<asac> i think starting with fbfev isnt good to add EDID - but have not looked closely
<ogra> well, but you know your pixel clock capability
<rcn-ee> that's one reason i always recommend the 720p value, it's the most compaitable and biggest..
<ogra> so you can fall back to something hardcoded
<ogra> its just evil to have to define *defaults* on the cmdline
<ogra> at least these should be there automatically
<ogra> i find it ok to *override* on cmdline
<ogra> but making it a requirement is just bad habit
<rcn-ee> pixel clock limitation is here; http://elinux.org/BeagleBoardFAQ#Display_resolutions_.232
<asac> ogra: do we have graphics drivers for beagle already?
<ogra> asac, from debian, yes
<asac> ogra: is that in archive and just works?
<rcn-ee> it's a sudo neon optimzed framebuffer driver...
<ogra> asac, havent tried yet
<rcn-ee> the guys at allwaysinnovating also did their own varient of that too..
<ogra> but yes, there is omapfb and omapfb with NEON
<ogra> we have two to pick from, not sure how good they are
<ogra> i'll test that once we have a working image
<rcn-ee> use the neon one...
<ogra> one step at a time :)
<asac> ogra: i guess we have neon in cpuinfo?
<ogra> if thats stable i will :)
<asac> shouldnt we just install both and it will pick the right one?
<ogra> asac, at least with the pre-built kernel amitk gave me
<rcn-ee> it's been the default in angstrom for a good year and half.. ;)
<asac> sounds promissing. nice
<ogra> rcn-ee, angstrom uses different toolchain
<ogra> so i wont say hooray until i tested it ;)
<rcn-ee> yeap, 4.3.3 vs 4.4.x..
<ogra> but yes, promising for sure
 * ogra wonders if 500.2 finally made it to the archive
<asac> ogra: does JamieBennett has a usable environment alÃ¶ready? maybe he can check that?
<ogra> asac, he should have everything he needs
<asac> ogra: whats the status on imx kernel in -proposed ?
<asac> :-P
<ogra> no idea, was it uploaded already ?
 * ogra didnt get any pings yet /me thinks
<rcn-ee> which reminds me.. did amit put the vfp patches you used for imx in omap's branch?  it needs it to..
<JamieBennett> asac, ogra, ping me in the morning if you want me to check something, about to leave the house in 10 minutes
<ogra> no idea, that kernel is fully his work, i only saw two binaries yet
<ogra> JamieBennett, just bring up your board tomorrow so you can test stuff
<asac> JamieBennett: ok. would like to have the omap x drivers checked ...
<asac> JamieBennett: 1. do both (neon + non neon) work
<rcn-ee> okay, well it's no in mainline yet either, so it would be easy to spot in the log..
<JamieBennett> ogra: will do, first thing I'll do in the morning
<asac> 2. is the right driver automatically selected if we install both
<ogra> asac, given the kernel is stable enough to even try :)
<asac> ogra: thought we are already there?
<rcn-ee> no, it won't... i had a user with that problem on karmic..
<ogra> for me 500.2 has multiple issues
<asac> hmm
<ogra> asac, its there but buggy
<ogra> usb didnt work
<ogra> which is somewhat essential on a beagle :)
<asac> did we backport their patches or just took the right upstream branch for .32?
<ogra> ext4 wipes the FS
<ogra> i think its plain mainline .33
<rcn-ee> asac, just a config issue on the usb..
<ogra> i see the modules loaded
<ogra> it oopsed when i unloaded
<asac> rcn-ee: cool. can you give ogra or kernel team pointers?
<ogra> though i didnt put much time into it yet, booting and image rolling is my current main concern
<ogra> once thats ready we can fiddle with the rest
<asac> ogra: right focus on that. jamie and rcn-ee can probably help if you spit out first iamges ;)
<ogra> especially *everyone* can as soon as we have daily builds :)
<rcn-ee> yeap, that's my goal.. ;) my staging area is here: https://code.launchpad.net/~beagleboard-kernel/+junk/lucid-ti-omap  and i got a good number of random omap boards.. ;)
<ogra> i want to extend our user base first :)
<asac> rcn-ee: can you reproduce the issues ogra mentioned?
<ogra> anyway, i'm really done now ...
<asac> ogra: see you tomorrow
 * ogra calls it beer o clock for real now
<rcn-ee> but we don't have enough boards yet for new users.. ;)
<rcn-ee> take it easy ogra.. ;)
<ogra> rcn-ee, revC
<ogra> there are lots and lots of users :)
<rcn-ee> asac, i forgot, what issue? ;)
<asac> rcn-ee: he said his beagleboard is unstable with current kernel in lucid
<ogra> USB and ext4 are the things i spotted yet
<rcn-ee> That's strange.. although i have ran 500.2 more then 5 minutes.. (boot [x], things work [x])
<ogra> unloading the twl driver makes it oops
<rcn-ee> but mailine 2.6.33 is stable for me..
<asac> rcn-ee: are you using lucid packages etc.?
<ogra> they are here if you look for them http://people.canonical.com/~amitk/ti/
<rcn-ee> yeap...  one beagle it's all chroots, another beagle it's different partitions with each dist
<rcn-ee> thanks ogra, will test those...
<ogra> i think at least ...
<ogra> i hust noticed they still say 500.1
<asac> thats 500.1
<asac> ack
<asac> where is 500.2
<asac> ?
<asac> in archive?
<ogra> i think that *is* 500.2 just wrongly versioned
<ogra> 500.2 was FTBFS this morning
<rcn-ee> i know amit was testing scripts...
<rcn-ee> asac, i know usb can be solved with: https://lists.ubuntu.com/archives/kernel-team/2010-March/009484.html  but the question is why desn't the twl stuff like being moderlized...
<rcn-ee> it could be timing with specially since CONFIG_TWL4030_USB sets the power regulator on the musb...
<nosse1> Are there any real speed or size differences between ARMv7 and earlier?
<rcn-ee> nosse1, think 486/686/etc.. ;)
<nosse1> heh
<nosse1> good answer ;)
<rcn-ee> it just gets more complicated since there are alot of x's.. x86...
<nosse1> theres an opinion here claiming that the 'x' of the distro doesnt really matter. The important stuff is the end-user app
<nosse1> so out of curiosity I was wondering if there had been any real (linux) benchmarking to it
<rcn-ee> nosse1, take a look at these, sheevaplug is armv5 and debian squeeze is built for armv4 http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-3173-25135-22766
<nosse1> rcn-ee, thanks
<rcn-ee> no problem, it was a fun comparsion test, i'm planning to redo it again, and add a iegp2 for comparsion, it has the same clock speed as the c4, but double the ram..
<comradekingu> I sent a mail to phoronix asking for them to test various arm distros and settings
<comradekingu> seeing they already have..
<rcn-ee> oh they haven't yet... ;)
<rcn-ee> I've talked with a couple of them at phoronix, they do have access to some arm boards..
<comradekingu> I asked about the latest developer boards, so i guess my question is still valid
<rcn-ee> yeap it is..  if you search for arm under their search_results, there is another anonymous user running tests other then me...
<comradekingu> With the barrage of ARM cellphones being released and the ever increasing software stack on there is think they should allot more time for it
<rcn-ee> yeap..  but you get these funny comparisions.. http://global.phoronix-test-suite.com/?k=profile&u=linuxeasecom-14106-16996-6522
<rcn-ee> (the lame and ogg) results are invalid on that one.. i should bug phronix, they are missing a dependicy..
<nosse1> Don't you think that there's a lot LFS out there for embedded targets such as ARM phones?
<comradekingu> Exactly
<nosse1> I mean in our product, it is quite new to endorse a distro. I'm living in the LFS/busybox compile-all-in-a-large-image kind of thing
<nosse1> I'm still not 100% convinced to deploy ubuntu into our product
<nosse1> Hopefully my playing around with ubuntu can change that. I'm certainly happy with Ub. on hosts
<comradekingu> Even nokia isnt alone in the mobile linuxworld anymore
<comradekingu> Only palm is i think
<nosse1> Since ubuntu is built natively, this implies that you build your own toolchains as well (don't use the popular CodeSourcery, or do you)?
<nosse1> All right, I think I finally got the qemu thing going. Tomorrow I will try it on real target.
<nosse1> If it still doesnt work, what is my approach for figuring it out? I know it started init, but I didn't get a login prompt
<nosse1> For all you guys helping me out: I hope I haven't annoyed too much. Thanks a lot for you help!
<jim_rees> How hard would it be to get ubuntu running on this? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=170414804289
#ubuntu-arm 2010-03-23
<Baybal> like arm v7 cortex a5 is faster arm 1136
<rcn-ee> an a5? it would need a lot of clockspeed...
<ojn> I haven't seen any performance comparisons. Has anyone announced A5-based SoCs yet?
<rcn-ee> one of the marvell ARMADA cores is.. and ti has one.. Haven't seen any numbers, but it should be slower then a8/a9..
<ojn> rcn-ee: really? I thought marvell designed their own cores. And which TI part has an A5? I've completely missed that announcement
<ojn> Seems like A5 has better DMIPS/MHz than 1136, but that doesn't mean that real-world performance is better.
<rcn-ee> well yeah Marvell does that in the end... but they say it's a5 compatable...
<ojn> A5 compatible means A8 compatible. I don't see the point in that statement.
<ojn> bzzt.
<rcn-ee> well, A5 is an 8 stage vs A8's 13 stage pipeline, but since Marvel designs it anyways, who knows what the difference is.. ;)
<rcn-ee> yeah sorry about that ti doesn't have a a5, i was getting their new Sitara 500Mha A8..
<rcn-ee> confused..
<ojn> rcn-ee: Yeah, you seem to be very confused. :)
<rcn-ee> and i think i'm going nutz, right now i'm 1/2 defconfig changes between a beagle and igep2 both working with ubuntu 500.2 kernel..
<rcn-ee> (dss2 omapfb stuff)
<cooloney> plars: hi, paul, did you test the daily build of UNE for fsl-imx51
<cooloney> plars: i can not enter X, just got a black screen, even beta1 release
<cooloney> plars: mine is bb2.5
<persia`> cooloney: Any interesting output on console?
<cooloney> persia: i can switch to console vt1
<cooloney> persia: and login with reentering a new password
<cooloney> persia: although i just need my console works firstly
<persia> What is the output of `date -u` ?
<plars> cooloney: yes, I tried it, worked fine for me
<plars> cooloney: I am on babbage 3 though, haven't tried on 2.5
<cooloney> plars: so weird
<cooloney> plars: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/
<cooloney> i installed this one
<cooloney> persia: Tue Mar 23 02:51:10 UTC 2010
<persia> OK, so that's not the date bug.
<persia> Does /var/log/Xorg.log have anything useful?
<cooloney> persia: i failed to find that. but live image works fine
<cooloney> just after installation, i boot from my hd, no X only black screen
<persia> And you can log in at a console.  Hrm.
<persia> And there's really no X log?
<persia> Does startx work?
<cooloney> i tried that, startx said X Server is running
<cooloney> persia: let me check the whole X log
<cooloney> i think X is running, but there is nothing on the screen, only a black one
<persia> Try launching an xterm from the console :)
<persia> `DISPLAY=:0.0 xterm &`
<cooloney> persia: xterm Xt error: Can't open display: 0.0
<persia> Try with sudo, just in case.
<persia> If that also doesn't work, try restarting gdm.
<persia> If that also doesn't work, the issue should really be in /var/log/Xorg.log
<persia> If you don't have that file, X didn't really start (although something may be wedged)
<cooloney> persia: i got the Xorg.log, but did not find any error
<persia> pastebin it?
<cooloney> persia: no problem,
<cooloney> persia: here it is http://pastebin.ubuntu.com/399667/
<persia> cooloney: And restarting gdm does nothing for you?
<persia> plars: Does that look like your output?
<cooloney> persia: yeah, nothing for me
<persia> I'm stuck.  Sorry.
<cooloney> persia: thanks anyway, I was stuck by the black screen since yesterday
<cooloney> no idea what happened to my board
<cooloney> persia: do you have bb2.5?
<persia> I don't have anything that can boot in direct comparison to what you have.
<cooloney> persia: i am apt-get upgrading, see if it will help somehow
<Baybal> hello
<Baybal> can you do startx
<Baybal> what is your display resolution?
<cooloney> Baybal: hi, i tried startx
<cooloney> but it said x is running
<Baybal> what is your display resolution?
<cooloney> and my display supports 1920x1080
<Baybal> lsmod please
<cooloney> http://pastebin.ubuntu.com/399678/
 * cooloney need some food. heads out for lunch
<Baybal> I suspect that concurrent db driver is running
<Baybal> you need to set video:
<cooloney> persia: so weird, after i did apt-get dist-upgrade, x works fine now
<cooloney> persia: thanks for taking a look
<cooloney> plars: thanks
<lool> persia: Did you understand the suggestion of infinity in the openbios-sparc bug?  I wonder how he meant we should build automatically with multiple sources -- I don't think it would be automatical and I'm not sure of the benefit of multiple sources
<lool> Hmm oo.o FTBFSed on armel
<lool> And I can't make any sense of its build log
<ogra> lool, i only see it failing on ia64
<ogra> oh, the ftbfs page is wrong :(
<wgrant> ogra: Wrong, or slightly out of date?
<ogra> wgrant, out of date i think, it only failed 1h ago
<wgrant> ogra: It should have rerun about 2 hours ago, but LP broke.
<ogra> ah, k
 * wgrant cranks the frequency up until LP people complain.
<ogra> hehe
<ogra> ++
<ogra> lool, do you know anything about versatile2 ? is it in mainline already ?
 * ogra wonders if it wouldnt make more sense to use a real cortex-a* kernel implementation instead of faking one 
<lool> ogra: versatile 2?
<lool> ogra: You mean versatile express?
<ogra> lool, no, 2 ... the arch that Martyn uses
<lool> ogra: Well try it out, I researched moving to realview versatile, but it didn't work
<ogra> cortex-a9 actually
<lool> qemu / upstream mismatch in features
<ogra> oh, verstile2 (V2) is actually express
<lool> See
<lool> and this is part of realview
<ogra> ah
<ogra> silly marketing departments ... too many names :P
<ogra> hmm, realview is only: ARM1136JF-S, ARM1176JZF-S, ARM1156T2F-S and Cortex-R4F
<lool> Not really
<lool> There are various boards and replaceable tiles
<lool> There's a cortex-a9 one
<ogra> ok
<ogra> just referring to the arm website here
<lool> You might be looking at the first realview board, but then they declined it in many variations
<ogra> ah
<lool> ogra: http://www.arm.com/community/software-enablement/linux.php?tab=Linux+OS+Downloads
<ogra> i also wonder where the beagleboard support for qemu went
<lool> I think one can build support for all of these in a single kernel, but only with a certain CPU level, so in practice some combinations wont work
<ogra> there was a GSoC project one or two years ago (i presented it at the berlin sprint)
<lool> hehe you presented it and you lost it?  :-)
<ogra> no, it was a hack back then
<lool> ogra: Don't present your keys!
<ogra> i know where on goodle it loves but i wonder if it ever was finished upstream
<ogra> *google
<ogra> *lives
<lool> goodle love baby
<ogra> oh my
 * ogra glares at his fingers and wonders if they want to tell him something
 * NCommander waves to ogra and lool 
<lool> NCommander: Hmm didn't you send pselect6/ppoll support to upstream QEMU?
<NCommander> lool: I did; it got committed
<lool> NCommander: Odd, I don't see support for pselect6() in linux-user/arm/syscall_nr.h o ntip
<NCommander> lool: *blink*
<NCommander> lool: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01067.html
<NCommander> lool: not sure what happened, they were supposed to land
<lool> NCommander: I think these are staged in suihkulokki's tree
<NCommander> lool: I guess suihkulokki's tree didn't land in the mainline git yet. I didn't follow up on the patch inclusion beyond suihkulokki's comment
<persia> lool: I did understand infinity's comment.  NCommander tried that approach several months ago in a PPA.  We need to modify Soyuz to make it work.
<NCommander> lool: persia: it mostly means touching build-dispatcher and archiveuploader, its fairly straightforward where changes need to be made
<lool> persia: I tried it as well and confirmed it's still an issue -- attached upload log to the bug
<persia> bigjools suggested we set X-Arch-Indep-Build-Arch in the .dsc, and have Soyuz parse that properly.
<persia> Which means adding XS-X-Arch-Indep-Build-Arch to debian/control, I think.
<persia> I'm unsure if there would also be benefit to adding it to the .changes file: needs investigation of the potential implentation.
<lool> I had the same intuition (adding an XS field)
<lool> I wish we'd discuss this on debian-policy@ though
<persia> lool: Doesn't affect Debian though: it's a Soyuz-specific issue.
<persia> Simply because the first upload in Debian must be source+binaries, the maintainer can force indep build affinity by selecting a build to sign an upload.
<lool> persia: Really?  How do you express this constraint in Debian source packages?
<persia> One just has to put a note in debian/README.source
<lool> I disagree, I think the Debian approach of uploading binaries is wrong as it requires access to specific hardware to upload the package
<lool> And it requires a by hand upload
<lool> The security team would be pained to upload an update for instance
<persia> I happen to agree with you, mostly because of all the arch:all packages that FTBFS.
<lool> And currently there's nothing indicating that this *can't* build on !specific-arch
<persia> Even after all these years, we're *still* commonly fixing issues with Java packages that can't build.
<lool> I actually discovered that the *two* packages fail to build on their respective arches!!
<persia> Hrm!
<persia> So the packages FTBFS in Debian as well?
<lool> I suspect openbios-sparc FTBFSes in Debian and openhackware might FTBFS if SSP is the default
<persia> openhackware built for me in Ubuntu about 9 months ago.  I haven't tried since.
<persia> I don't have hardware to test-build openbios-sparc.
<lool> persia: openhackware required -fno-stack-protector to build for me
<lool> I'm surprized you weren't hit by this even 9 months ago
<persia> All I did was apt-get source, sbuild.  I didn't examine the logs.
<persia> Or maybe it was a different package
 * persia looks
<persia> I may be misremembering, and I may have tried to build openbios-ppc
<lool> NCommander: Did you see oo.o ftbfsed?
<NCommander> lool: ugh
 * NCommander cries
<NCommander> lool: I think the buildd went weee *splat*
<NCommander> lool: probably worth smashing retry
<NCommander> lool: unless you have a better idea, I'm going to hit retry and see if it happens again
<lool> NCommander: Hmm ok
<lool> The build log didn't make sense to me, but then I'm not an oo.o dev really
<NCommander> lool: it seems to me the buildd just went plunk. They sometimes blow up on OOo due the sheer size
<lool> suihkulokki: Is there some ML where you folks coordinate qemu-maemo stuff?
<lool> amitk: Is there a beagleboard vmlinuz from linux-ti-omap somewhere out there?
<ogra> lool, http://people.canonical.com/~amitk/ti/ (the versioning is wrong afaik, its 500.2)
<lool> thanks
<amitk> lool: use this one to be sure: http://people.canonical.com/~apw/ti-omap-lucid/
<ogra> lool, oh, wait http://people.canonical.com/~apw/ti-omap-lucid/
<ogra> is the right one
<ogra> bah, snap
<ogra> lool, i can give you an initramfs too if you want one (or uImage/uInitrd)
<ogra> and a boot.scr
<dmart> asac, I do get the firefox problem over ssh to a non-Babbage board
 * dmart waiting for babbage to reboot
<asac> dmart: i see it here on bbg through ss
<asac> h
<asac> and dove i am checkin gnow
<asac> its just that ubuntu.com doesnt show the problem
<dmart> I'm wondering whether it's some weird rounding issue where firefox rounds the size of images down and then adds scroll bars to compensate
<dmart> Google maps is the best example I've found so far...
<asac> feels like
<asac> dmart: did you see the chromium bug on dove? it feels like a rounding issue too ;)
<dmart> I don't have dove to look at :(
<asac> but lets focus on this one
<asac> dmart: join #developers on irc.mozilla.org
<NCommander> dmart: I get the FF problem on Dove
<lool> amitk: Did you already use beagle kernels directly in qemu?
<amitk> lool: nope
<asac> dmart: so lets wait a bit there and ping again in a couple of hours
<asac> vlad is the guy that usually knows about arm
<ogra> lool, http://code.google.com/p/qemu-omap3/
<ogra> that was the one i had in berlin
<lool> ogra: Yeah, is there a way to run it like we run the versatile stuff?
<lool> Or does one has to create the nand flash stuff in all cases?
<ogra> it only runs from NAND
<ogra> no disk or MMC support :/
<lool> Also, what's the canonical upstream for the bb_nandflash.sh and bb_nandflash_ecc.c stuff?
<ogra> no idea
<ogra> it wasnt ready back then, so i didnt follow it deeply
<ogra> (and we had no omap support)
<dmart> lool: re your bug post that OOo ftbfs again on armel, it looks like https://launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0-4ubuntu1 is still building for armel.  Is this a retry or a different version?
<ogra> dmart, retry
<dmart> Is the log from the failed build around somewhere?  What went wrong?
<lool> dmart: It's a retry
<lool> dmart: Apparently some obscure error like the shell failing; it seems this happens regularly on babbage 3
<dmart> I see a bash SEGV in the eglibc ftbfs
<dmart> I'm doing a build to see if I can reproduce that
<ogra> lool, s/babbage 3/pegatron/
<ogra> babbage3 is stable
<dmart> oh, args
<dmart>  /argh
<dmart> I'll leave that build running anyway... you never know.
<asac> dmart: will be a few minutes late to call :( ... sorry, lost my time
<dmart> The call is in 1 hour?
<lool> .c
<ogra> .sh
<asac> dmart: according to my calendar now
<asac> but noone is there
<asac> dmart: ?
<asac> dmart: ping us if the cfall i snow
<asac> otherwise talk to you in 50
<asac> dmart: http://launchpadlibrarian.net/39762270/klibc-thumb.patch ... is that armv5 compatible?
<asac> also armv4t?
<suihkulokki> lool: I guess the normal qemu-devel would do
<dmart> asac: Is all the affected code inside #ifdef __thumb__ or similar?  We might want to avoid bx when building in ARM for older architectures (to avoid making builds fail for other people)
<asac> dmart: armv4t and above should do bx, right?
<dmart> Yes
<asac> its not guarded by anything
<dmart> Otherwise, your changes look sensible
<asac> we just wonder if we should really care for older stuf
<asac> i thought we said we dont care for anything before armv4t
<dmart> If it's inside #ifdef __thumb__ you're OK, but otherwise you might want checks similar to what we've already done in other packages.
<asac> dmart: bx is only __thumb__ ?
<asac> or do we need to match: armv4t armv5 armv6 armv7 ?
<ogra> why would you ?
<ogra> we only build v7
<asac> upstream
<asac> i wouldnt ask all this if it was about us
<ogra> well, upstream wants to be run in debian too i guess
<lool> suihkulokki: Ok; got my email?
<dmart> For: #ifdef __thumb__  ... bx ... #else ... bx ... #endif
<dmart> The second bx might need some protection if we want to be compatible with pre-armv4t processors.  But as asac says, maybe we don't care about that.
<asac> i will try to get that upstreamed without any protection
<asac> unless you shout
<asac> if they say they want to support older stuff we can clean it up
<dmart> ok ... either is should not cause a problem or it will ftbfs for someone (which is relatively easy to fix)
<dmart> "no problem" is the more likely
<dmart> asac: Just before you post, can you check where the value we bx to comes from?  It is just the return address passed to the function?  If it's computed or something, we might have to worry about interworking.
<asac> dmart: i think we checked that when we made the patch
<dmart> OK, I don't recall the details now.  Sounds plausible.
<asac> dmart: oh klibc is build with -mno-thumb-interwork   -Os -march=armv4 -mtune=strongarm
<asac> so atm it complains about target cpu not supporting thumb instructions ;)
<dmart> When is klibc used?
<dmart> Interworking is mandatory for EABI iirc
<dmart> ... so it may be wrong to use these build options if klibc is supposed to interoperate with "normal" binaries
<asac> dmart: its used by initramfs
<asac> -mabi=aapcs-linux
<asac> -mabi=apcs-gnu
<asac> dmart: ... any clue what those mean?
<asac> either of that i used on arm for klibc
<prpplague> davidm: you still in the DFW area?
<lool> Does someone have a mtdblock .bin file for beagle which does something useful I could test qemu with?
<dmart> asac: -mapi=apcs-gnu is the legacy ABI (as used by the Debian "arm" port).  Not sure about -mabi=aapcs-linux
<dmart> Do you know what klibc is used for?
<asac> dmart: just in initramfs where there is no libc available
<asac> for more details we need to check with cjwaston on -devel
<dmart> What gets built against it?  If they mess with the ABI then everything would need to be built with the same options...
<asac> we can figure that
<suihkulokki> lool: pushed fixed version to gitorious
<asac> dmart: for main checkout http://archive.ubuntu.com/ubuntu/dists/lucid/main/source/Sources.gz and search for klibc-dev
<dmart> What's not clear to me is why a weird ABI is used for this at all... maybe it is just for historical reasons.  If so we should consider bring it up to the lucid defaults.
<dmart> asac: I'll take a look
<asac> dmart: so dmraid
<asac> and rootskel
<asac> for universe in http://archive.ubuntu.com/ubuntu/dists/lucid/universe/source/Sources.gz
<ogra> klibc is only shipped in initramfs, its not used
<ogra> we ship glibc as well
<asac> ogra: why do we ship it then?
<ogra> asac, no idea
<asac> dmart: cowdancer
<lool> suihkulokki: thanks
<ogra> cjwatson might know
<asac> is the one in universe using it
<asac> ogra: the packages from above build depend on it
<asac> so i guess they also use it?
<lool> suihkulokki: are you rebasing this regularly?
<lool> I guess you are, that's fine, just would like to know
<ogra> lool, do you have an idea ?
<ogra> (why we ship klibc in initramfs even though everything is linked against glibc)
<asac> ogra: what about dmraid, rootskel and cowdancer?
<suihkulokki> lets see how much time IÍ'll have
<asac> why do those build depend on it?
<ogra> asac, hmm, these might probably use it (though its pontless, they could as well use glibc since thats already there anyway)
<lool> suihkulokki: I mean rebasing versus merging
<suihkulokki> that branch should be rebased rather than merged
<lool> ok
<dmart> Is a special build of glibc used for the initramfs?
<asac> ogra: ?
<ogra> asac, there is no reason for them to build-dep on klibc in ubuntu
<ogra> it might be something we inherit from debian
<ogra> not sure
<ogra> but effectively klibc is pointless in our setup
<dmart> The problem I see is that building klibc with the build options currently used makes no sense because then any binary needs to be specially built for use in the initramfs --- due to the incompatibility with the lucid compiler defaults.
<ogra> right
<ogra> and we have glibc anyway in the initramfs in ubuntu
<asac> ok
<asac> dmart: so we should try to just build without any special options?
<asac> let me do that ;)
<dmart> Might be worth trying.  Should we ping cjwatson for more understanding of why klibc is in there?
<ogra> probably
<ogra> though he might also only have second hand knowledge ... initially all the initramfs infrastructure was designed by jeff bailey who isnt ubuntu dev anymore
<asac> dmart: so seems we need to fix it or leave it ;)
<asac> dmart: http://paste.ubuntu.com/400080/
<asac> what should i drop on top ;)?
<lool> PPAs are so backlogged
<lool> suihkulokki: New branch looks all good; thanks!
<asac> lool: please call cr3 at home
<lool> asac: Eh
<asac> its probably a script failure again, that dont reinject the 10 more oppa builders we have
<asac> we had that in the past ... thought it was fixed, but it seems not
<lool> asac: My builds are showing 6 hours delays
<lool> asac: is that normal?
<asac> lool: native or virtual ppa?
<asac> lool: its normal that if QA pulls out their builders and forgets to put them back that the queue grows infinitely
<asac> and you can even have 24h or more backlog
<asac> its QA treating us bad ... i always thought there was sense in this, but after discussing i found that the builders should never be away longer than 2h ;)
<asac> so everytime we have 5 instead of 15 for longer than a few hours, QA forgot about us ;)
<lool> asac: virtual
<asac> yeah. thats QA forgetting to put back the builders (or really doing long running test which is unlikely)
<asac> oh ... but now we have 9 again
<asac> so i think they are back (maybe not all)
<asac> the queue should recover in a day or so
<lool> a day, ugh
<asac> yeah. there are 600 builds waiting ;) ... what do you expect?
<asac> you can bribe a buildd admin and get your build score bumped
<asac> but we all have to suffer ;)
<ogra> lool, just send IS your beagles ;)
<lool> I only have one, and one I actually *cought*!
<lool> her *bought*
<lool> *Er
<lool> I'm tired
<ogra> heh
<lool> asac: It's ok, I'll sit on it
<lool> I pushed a qemu-maemo upload and am eager to share it, it's good stuff
<lool> But it doesn't help the glib test failure
<lool> ogra: I'd try it with your installation issue
 * ogra would love if it would help the rootstock hang
<lool> ogra: did you try with cache=writeback?
<ogra> not yet
<ogra> omap kept me busy
<asac> lool: qemu-maemo? what platforms get adde there?
<ogra> i havent touched rootstock since last wed
<ogra> asac, omap
<suihkulokki> lool did you try it with ubuntu ?
<asac> cool
<lool> suihkulokki: What do you mean with ubuntu?
<lool> suihkulokki: it boots our versatile kernels just fine
<lool> and our userspace
<dmart> asac: re klibc, we might need to look at it more carefully... they are quite specific about ABI options etc., so I'm wondering whether there may be more assembler which makes assumptions which may break if we change things.
<suihkulokki> lool: i understood you now have a omap3 kernel?
<lool> so I tried both under ubuntu and running ubuntu
<lool> suihkulokki: No that's what I wanted to do
<ogra> suihkulokki, you wish ... its stuck in NEW
<dmart> asac: we should probably discuss klibc further tomorrow
<lool> suihkulokki: But I don't know how to try it
<lool> suihkulokki: I grabbed the sample files from the qemu-omap3 project and their scripts to create a mtdblock.bin, but I'd rather point qemu-maemo straight to xloader, or uboot or kernel + rootfs, and I don't know how to do this
<lool> I think I should look at the available -boot options
<suihkulokki> lool: if you have a bootable beagleboard sd, just -m beagle and -sd /dev/sdcard
<lool> suihkulokki: that didn't work for me
<lool> let me try again
<suihkulokki> or a file image of the sd
<lool> suihkulokki: qemu-maemo-system-arm -M beagle -sd lucid.img
<lool> qemu: hardware error: no boot device found
<lool> Hmm what I'm trying can't work
<lool> suihkulokki: What does it expect on the SD?  vfat + MLC / u-boot.bin?
<suihkulokki> and lucid.img includes the uboot part?
<lool> No
<lool> I need to build something suitable, but I don't know what it is
<lool> suihkulokki: What I just tried is a 100M vfat with the u-boot.bin + MLC (x-loader.ift) + uImage from the qemu-omap page
<lool> suihkulokki: But same error
<lool> The only thing which progressed a bit was -mtdblock somenand.bin which I created using the qemu-omap3 tools
<ogra> did you try using -hda instead ?
<lool>     if (!dmtd && !dsd) {
<lool>         hw_error("%s: SD or NAND image required", __FUNCTION__);
<lool> Weird, I don't even get that message
<lool> err so I should call it MLO, not MLC
<lool> Gah, forgot to create an actual partition table
<ogra> MLO needs to be copied first into the vfat !
<ogra> it needs to sit at the first blocks
<lool> Ok so now I have a real image with a single vfat partition with a MLO and it still fails
<ogra> lool, might be that the size matters
 * ogra digs up the reciepe he used to get his beagles up
 * prpplague reads the scroll back
<ogra> lool, http://paste.ubuntu.com/397188/
<ogra> that definately boots on all my beagles here
<prpplague> you also need to make sure that your xloader/mlo file has been signed with gpsign
<prpplague> basicaly just adds a header with the size and location to load the file
<ogra> prpplague, the one from the ubuntu package is definately signed
<prpplague> ogra: ahh part of the build?
 * lool just took an image of his SD card
<ogra> yep :)
<prpplague> dandy
<lool> Still no luck
 * lool goes a for a debug build
<lool> actually I had that multi SD card patch disabled in my version, perhaps that's it
<ogra> ah
<ogra> well, a working MLO should at least get you some console output
<lool> Gah I rebuilt with #define OMAP3_BOOT_DEBUG and I see nothing
<abdalla> Hello, Anyone here from Canconical Company..Please I want to ask a question?..Thanks in Advance
<Gopal> Hello, I used linux-image-2.6.32.10-zippy2.x12_1.0karmic_armel.deb to build he beagle board ubuntu
<Gopal> but my keyboard is not working and no usb devices attached is working, can some tell me what is going on here
<lool> Gopal: I'm afraid this kernel isn't from Ubuntu
<lool> Gopal: Check with whom you got it from
<Gopal> lool: OK thanks
<Gentooer> Hi, I keep seeing stuff about Ubuntu on Marvell Dove and Freescale Babbage boards. Where do you guys actually get these boards? Are they for sale to the public?
<NCommander> Gentooer: they aren't sadly
<armin76> heh
<armin76> Gentooer: funny you being a gentooer and being in here :P
#ubuntu-arm 2010-03-24
<DanaG> ooh, new omap kernel in repos... cool.
<DanaG> Just need to figure out how it does postinst. =P
<persia> dpkg -e is your friend
<DanaG> dpkg -e does absolutely nothing on that deb.
<DanaG> and dpkg --help doesn't list a -e.
<persia> Are you sure?
<persia> dpkg -e foo.deb BAR should extract all the metacontent in the .deb to BAR
<DanaG> dana@beagleboard:~$ dpkg -e linux-image-2.6.33-dl.1_1.0lucid_armel.deb
<DanaG> dana@beagleboard:~$
<persia> OK
<DanaG> er
<persia> ls
<DanaG> wrong file
<DanaG> does it need absolute path?
<persia> ls anyway :)
<persia> No.
<persia> Just enough path to find it.
<DanaG>  dpkg -e /var/cache/apt/archives/linux-image-2.6.33-500-omap_2.6.33-500.3_armel.deb -- does nothing.
<persia> Are you sure?
<DanaG> yeah.
<persia> Did you look for new files that may have been created?
<DanaG> oh.
<DanaG> I see.
<DanaG> DEBIAN dir.
<DanaG> still, why does --help not show -e?
<armin76> fail
<persia> Probably because it's really a dpkg-deb command that dpkg just passes through.
<persia> It's definitely shown in `man dpkg`
<DanaG> init: ureadahead main process (45) terminated with status 5
<DanaG> happens on my host system, too...
<DanaG> ureadahead seems not to like non-generic kernels.
<DanaG> ugh, ubuntu -500-omap kernel can't read mtd devices!
<DanaG> er, maybe my mtdparts got broken.
<DanaG> argh, u-boot won't see some of the files on my fat32 partition.
<DanaG> Unhandled fault: external abort on non-linefetch (0x1018) at 0x402e1000
<DanaG> well... the thing now goes into suspend... but how do you wake it?
<cooloney> hi, does anybody know how does NetworkManager know this "<info>  (eth0): driver 'fec' does not support carrier detection"?
<DanaG> OMAP3 beagleboard.org # mtd erase 260000 20000
<DanaG> mtdparts - define flash/nand partitions
<DanaG> argh
<DanaG> oh
<DanaG> right
<DanaG> nand erase
<DanaG> sorry, thinking out loud about my own stuff.
<DanaG> looks like that lucid omap kernel is screwed up somehow.
<JaMaWrk> Is there some un-official repository with ubuntu but built for armv4t instead armv5t/armv6/armv7 for jaunty/karmic/lucid? I know I can use debian (as I already do), but I'm interstad in additional ubuntu stuff (except being rebuilt for newer arch). If no, do you know someone who tried and failed to provide this repo?
<persia> There isn't such a repository.
<persia> There have been a couple people who said they wanted to try, but it takes months to recompile everything, and I don't know of anyone who actually did it.
<JaMaWrk> OK fair enough, thanks
<cooloney> ogra_cmpc and persia: i already enabled phylib and carrier detection in fsl-imx51 fec driver
<cooloney> plars and GrueMaster: could you please help me to test it? ^^^
<cooloney> i already did that on my babbage board.
<lool> cooloney: Sounds great
 * lool doesn't have hardware to test though
<cooloney> lool: why not enable that in qemu? and test it? haha -:))
<ogra> cooloney, yeah, lool should really hack imx51 support into qemu !!
<ogra> and add a virtual 2G :)
<ogra> persia, heh, i see the first netwalker user on the ubuntu-users ML ... being desperate, he wants to upgrade
<lool> cooloney: Yeah!  Let's do that during the next 2 years!  :-0
<dmart> asac: hi there
<dimitris> any gps navigation program ? I use ubuntu in arm (HTC diamond armv6)
<dimitris> or at least any suggestion to see if gps is working
<persia> There are a few, but I don't think any of them work very well at lower resolutions :(
<Stskeeps> tangogps
<persia> Oh, cool!  I didn't know we had that already.
<dmart> asac: ping
<asac> dmart: yup
<dimitris> tangogps there is not in repository !
<dimitris> I find gpsdrive
<lool> ogra: Do you have details on why you disabled LDFLAGS in u-boot?
<ogra> lool, because we set -Wl
<ogra> and the build doesnt like that
<lool> ogra: Which cc were using that with?
<ogra> default on the babbage board
<lool> ogra: So with armel gcc?
<ogra> lucid
<ogra> yes
<lool> native build
<ogra> it sets -Wl,-Bsymbolic-functions iirc
<lool> ogra: Was it -Bsymbolic-functions?
<lool> Ok
<lool> ogra: I don't actually understand where the issue is there
<ogra> the -Wl made it break (i didnt find it in ld's help output)
<lool> ogra: man ld has it
<ogra> if you find a fix i wont complain :)
<lool> It's in the --help output as well
<lool> arm-linux-gnueabi-ld: unrecognized option '-Wl,-Bsymbolic-functions'
<lool> That's the failure I get when cross-building
<ogra> that was the same i had
<ogra> using the native ld
<lool>                 cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
<lool>                         --start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
<lool>                         -Map u-boot.map -o u-boot
<lool> I don't understand why it says unrecognized
<ogra> well, but it does :)
<lool> ogra: It certainly works with all the other packages, doesn't it?
<ogra> no idea, i never ran into it so i wouldnt know
 * ogra waits for his babbage to come up
<ogra> i'm 100% positive there was no -Wl in ld --help
<arthur-> ogra: -Wl,foo tells *gcc* to pass foo to ld
<arthur-> but if you use ld directly, you just pass foo
<ogra> ogra@babbage2:~$ ld --help|grep Wl
<ogra> ogra@babbage2:~$
<ogra> right, so its wrong in the LDFLAGS in this case
<arthur-> $ gcc --help  | grep Wl
<arthur->   -Wl,<options>            Pass comma-separated <options> on to the linker
<ogra> yeah
<ogra> but look at lool's example above
<ogra> $(LD) $(LDFLAGS)
<ogra> it calls ld directly
<lool> arthur-: You think it's because it's passing -Wl to ld?
<lool> That might be
<arthur-> lool: depends on what $(LD) is
<ogra> very likely because the whole source is set up for cross compiling by default
<ogra> which we dont do at all
<ogra> arthur-, LD is ld :)
<lool> arthur-: it's ld
<lool> or a cross-ld
<lool> I guess the bug is that they should call gcc for ld
<arthur-> lool: if this can work, this is what they should do yes
<arthur-> lool: what is the full command (given by make output I guess)?
<lool> LD      = $(CROSS_COMPILE)ld
<lool> CC      = $(CROSS_COMPILE)gcc
<arthur-> it's maybe possible to use gcc+objcopy instead of ld
<lool> arthur-: http://paste.ubuntu.com/400594/
 * lool tries biulding with -B... in LDFLAGS
<ogra> -Bsymbolic-functions surely works
<lool> ogra: You tried?
<lool> arthur-: yeah that's the issue
<lool> So upstream should have CCLD = $(CC) or something like that
<ogra> lool, no, but i know that -Bsymbolic-functions is supported by ld ... while -Wl isnt
<ogra> lool, feel free to discuss with sarkoman in #beagle :) he is upstream
<ogra> though i think we're pretty unusual in the light that we build everything natively ... nobody usually does that for x-loader or uboot
<lool> It's not a problem of building natively
<lool> it's a problem of setting the same type of LDFLAGS for all software you build
<lool> I have the same problem cross-building u-boot
<ogra> ah
<arthur-> lool: you can get ride of dpkg's ldflags here anyway, I guess there is no shared lib in u-boot
<lool> arthur-: Well it builds some tools, but I prefer not dropping LDFLAGS entirely
<lool> I added a snippet to convert them
<lool> I thing it makes sense to turn on -O1 for all packages for instance
<ogra> feel free to add it to the package
<arthur-> lool: it it built from a regular debian process? (debian/rules, etc)
<ogra> arthur-, yes
<lool> arthur-: built and cross-built, yes
<ogra> https://launchpad.net/ubuntu/+source/u-boot-omap3/2010.3git20100315-0ubuntu3
<arthur-> then at the beginning of dbeian/rules, you can add something like
<arthur-> define unsetenv
<arthur->   unexport $(1)
<arthur->   $(1) =
<arthur-> endef
<arthur-> $(foreach v, CPPFLAGS CFLAGS CXXFLAGS FFLAGS LDFLAGS, $(if $(filter environment,$(origin $(v))),$(eval $(call unsetenv, $(v)))))
<arthur-> with a comment which says ubuntu flags are not made for building a boot loader :)
<lool> arthur-: I did LDFLAGS := $(patsubst -Wl$(comma)%,%,$(LDFLAGS))
<ogra> well, it currently has unexport LDFLAGS at the top of rules
<lool> Which I think is nicer
<ogra> and the binary works fine
<lool> ogra: I didn't like unexporting LDFLAGS completely
<ogra> indeed
<ogra> there is always room for improvement :)
<lool> The first thing I did was replacing this with LDFLAGS := $(filter-out -Wl$(comma)-Bsymbolic-functions, $(LDFLAGS))
<ogra> i just needed a binary package for image building for now
<dmart> asac: hi again... sorry, I got distracted
<dmart> asac: see http://pastebin.ubuntu.com/400604/ for some code which adds some additional bx in the ARM-specific code.  It's probably best to have this for completeness, though it looks like the build flags for klibc and everything built against it may make this unnecessary.  We might want to protect with #ifndef __ARM_ARCH_4__ but we can probably consider <=armv3 obsolete for now.
<ogra> dmart, did you see https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/457878/comments/8 ?
<ubot4`> Launchpad bug 457878 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "imx51 on board ethernet plug/unplug events not detected (affects: 2)" [Medium,In progress]
<ogra> please test with your hub
<ogra> it seems to solve a bunch of other issues so i'm hopeful
<dmart> ogra: yes, currently in the process of testing it
<dmart> I broke my boot SD card somehow, so I'm installing today's daily-live
<ogra> ah
<dmart> I'm hoping this will fix the problem
<ogra> lool, you are such a nitpicker !
<ogra>  * rules: minor whitespace cleanups.
<ogra> heh
<lool> ogra: Well my eyes bleed when I see \t\t before each command in rules
<lool> (instead of \t)
<lool> Not that it breaks anything but still
<ogra> well, my vim is set up for python :)
<ogra> using four spaces for tabs
<lool> You should use your python setup *when editing python*
<ogra> pfft details :)
<lool> I hate usage of tabs outside of makefiles  :-(
<ogra> thanks for the fixes !
<lool> np
<lool> It cross-debuilds now
<lool> ogra: Did you push an x-loader package for bb?  and do you plan to add udebs to u-boot / x-loader?
<ogra> i didnt plan udebs, no
<ogra> lool, https://launchpad.net/ubuntu/+source/x-loader/
<lool> ogra: thanks, seems to suffer from similar issues
<ogra> yup
<ogra> could need the same fixes, though note that there is a quilt patch to override the hardcoded CROSS_COMPILE in the Makefile
<lool> Why didn't you put signGP.c in debian/>
<ogra> seemed appropriate as a patch
<ogra> i might replace it by gpsign.c anyway
<lool> ogra: what's the license of signGP.c?
<ogra> lool, GPL2 the prob is that it is not added to it anywhere
<ogra> lool, which is the reason i'm considering gpsign.c instead
<lool> ogra: Where is it stated?
<ogra> lool, jkrindner stated that to me on IRC
<lool> ...
<ogra> but its not historically recoverable
<ogra> http://github.com/nmenon/omap-u-boot-utils/blob/master/src/gpsign.c
<ogra> its the same author (and accorting to jkrinder the same license)
<ogra> but apparently it got checked in to the TI git without any further info
<lool> ogra: What's $(sh) for in rules?
<ogra> lool, i'll switch to gpsign but i havent found the time to test if it gets the same MLO for us yet
<ogra> $(sh) execs a shell command, no ?
<ogra> in a way that i dont need to convert it to make
<lool> ogra: it's $(SHELL), but every line in a makefile target is run through SHELL
<ogra> i had issues with that in the past
<lool> ogra: $(sh) expands to nothing and is ignored, see your build log
<ogra> hrm
<ogra> well, then it can as well go away
<ogra> if you touch the package feel free to do so
<hrw> ehlo
<prpplague> oh lord, who let hrw in here
<hrw> prpplague: haha
<hrw> prpplague: I am surprised seeing you here
<prpplague> hrw: hehe indeed
<prpplague> hrw: i'm not a big ubuntu fan, but my current contract has ubuntu requirements
<ogra> sensible customer then :)
<hrw> prpplague: ubuntu on arm?
<ogra> prpplague, why dont i see you in #ltsp anymore ?
<prpplague> ogra: yea you could say that
<prpplague> hrw: yea
<hrw> prpplague: nice.
<hrw> prpplague: omap3 or other?
<prpplague> ogra: just never do any LTSP items any more
 * ogra will work on full omap integration for ltsp in 10.10 
<prpplague> hrw: omap
<prpplague> ogra: dandy
<hrw> omaps are everythwere
<hrw> next week I will find one in fridge and start screaming
<prpplague> ogra: you using beagle boards for that?
<ogra> well, beagles didnt make good thin clients in the past due to the missing NIC
<ogra> but that might change :)
<hrw> ogra: beware - prpplague will sell you zippy2
<prpplague> ogra: hehe, *cough*
<prpplague> ogra: you can always use a zippy or zippy2 with the revC boards, and the new beagleXM has usb ethernet
<prpplague> main problem with the beagle board is that there isn't a good case for it
<ogra> i think i saw some nice cases
 * prpplague had planned to do the DogHouse, but backed out on it
<ogra> lool, dont you have a beagle with case ?
<lool> ogra: I do
<prpplague> ogra: http://www.elinux.org/DogHouse
<prpplague> lool: that the plexiglass case from special computing?
<hrw> prpplague: usb ethernet + omap3... arhg combo
<lool> prpplague: Yes
<nosse1> ogra: I ran into a issue where I need to run qemu for a openembedded target and it complains about mmap_min_addr not set to zero. I see from a changelog in qemu-kvm that it is set to 4097. Is there any dangers/consequences for me to override it to 0?
<jaustin> is it 'normal' for the moment that I'm seeing dependency issues with xubuntu-desktop in lucid? Seems to come down to libgtk2.0 not being at 2.20 yet
<prpplague> ogra: you still doing alot of LTSP work?
<ogra> nosse1, yes
<ogra> nosse1, if you can avoid 0 you should
<ogra> prpplague, sadly not
<prpplague> ogra: ahh
 * prpplague was big into LTSP from around 1999 to 2002
 * ogra wrote most of ltsp5 until hardy
<ogra> since then i moved over to mobile and got sucked into other work
<prpplague> ogra: hehe i even had LTSP running on ......... SCO OpenServer
<hrw> nosse1: qemu 0.12 does not need that setting anymore
<ogra> hrw, for the syscall translation layer ?
<ogra> lool, ^^^ did you know that ? we should drop it if its true
<prpplague> btw, if anyone wants to provide feed back on things that they don't like about the beagle, i'd appreciate it
<nosse1> ogra, thanks. It's probably an old security check which I can override
<prpplague> (as well as wish list accessories)
<lool> ogra: Did you try it out?
<hrw> prpplague: I would like to have ftdi serial+jtag on miniusb
<hrw> prpplague: like in sheevaplug
<ogra> lool, nope
<prpplague> hrw: hehe , flyswatter isn't good enough for you eh?
<hrw> prpplague: and 4port usb hub integrated
<suihkulokki> and a pony?
<prpplague> hrw: the 4port hub will be in beagleXM
<dmart> asac: ping?
<hrw> suihkulokki: two of them
<ogra> suihkulokki, sounds more like a herd of ponies :)
<hrw> prpplague: I do not have it
<prpplague> hrw: beagleXM or the flyswatter?
<hrw> both
<prpplague> hrw: why the heck not?
<prpplague> hrw: anything else you'd like to see on the beagle?
<hrw> prpplague: beaglexm looks like TI internal so far, flyswatter (or other jtagger) was not needed for me so far, except neo1973 but for this I have debugboard
<prpplague> hrw: flyswatter is pretty handy to have around
<nosse1> Coming back to my AM3517-EVM ubuntu bringup: I have now a working qemu running. And I am capable of booting and mounting the ubuntu root (either from NFS or SD). However it crashes during starting (i.e. after init has started but before login) with the error "init: procps main process terminated with status 255"
<prpplague> hrw: yea, the XM isn't public yet
<prpplague> nosse1: oh you have a AM3517 board?
<nosse1> Yes
<hrw> prpplague: my next home project is beagleboard + wifi + bt + usb hub + serial + hdmi
<ogra> nosse1, sounds like your kernel is missing something
<nosse1> trying to get it up now
<prpplague> hrw: when are you planning to do that?
<jaustin> the IGEPv2 has Ethernet+Wifi+Bluetooth on board, makes things very tidy
<prpplague> nosse1: dandy, i'd love to get one of those up and running with socketcan for the canbus stuff
<hrw> prpplague: next month, have all parts available so it will be size of two beagleboards side by side
<hrw> jaustin: I have 3 beagleboards here
<nosse1> ogra, yes it's probable the kernel is foo, because I'm using on delivered with the evalkit. How do you in debian world compile the kernel? (...given that I dont have a running target yet)
<hrw> nosse1: tried OpenEmbedded kernels?
<ogra> nosse1, there are docs for this somewhere on the ubuntu wiki and the guys in #ubuntu-kernel can help i guess
<prpplague> nosse1: going to do anything automobile related with your board?
<nosse1> hrw: Indirectly I guess, since TI uses Aragon, which is based on ÃngstrÃ¶m (which is based on OpenEmbedded) *puh*
<hrw> Arago
<dmart> ogra: Looks like Bryan's kernel fixes my slow Ethernet \Ã¼/
<nosse1> ogra: Thanks, I'll check it out. Principally I can cross compile the kernel (with no modules) and then perhaps build a native ubuntu kernel when the target it running
<lool> dmart: Are you on a German keyboard?  :)
<dmart> no, I just got a bit creative...
 * lool finds it very delicate to send umlauts to ogra
<armin76> lol
<nosse1> prpplague: Not automotive, but semi-medical. I'd be happy to talk about it, but I think my boss it not...
<dmart> Ã¼ is the nearst I can get to a vertial smiley face in iso8859-1
<dmart> graphical dingbats would obviously be cheating...
<prpplague> nosse1: hehe, np, i have the same restrictions
<ogra> lool, lol
<ogra> dmart, yay !
<ogra> i *knew* it !
<dmart> I'll wait for the real .deb, but it looks good
<nosse1> Is there a "set -x" or debug setting in upstart for it to output every stage of the init/boot process?
<ogra> i dont think so
<dmart> nosse1: upstart init has a -v or --verbose switch
<ogra> right, but hosw do you call that
<ogra> *how
<dmart> When I need this I typicall boot with init=/bin/bash and then exec init manually
<ogra> oh, indeed ;)
<dmart> init=/sbin/init -v  may also work if it's at the end of the kernel command line
 * ogra was wondering if init= can take arguments
<nosse1> I can try that
<dmart> I also find it useful to pass --debug to mountall in /etc/init/moutall.conf, if you're getting filesystem mounting problems
<ogra> yeah
<dmart>  /mountall.conf
<dmart> init= _can_ take arguments ... init=/bin/bash blarg  ->
<jaustin> How can I debug random restarts when using 91.0 and 2.6.33.1?
<dmart> bash: Cannot execute blarg
<dmart> PANIC
<dmart> (etc.)
<ogra> ah, i never tried that
<jaustin> I don't see anything special over the serial console, it just restarts
<ogra> i would have expected you need some magic quoting
<jaustin> I'm using an IGEPv2
<plars> dmart: this was the one where it was slowing down when going through a hub, but not a switch?
<dmart> plars: yes
<plars> dmart: good to hear :)
<nosse1> dmart: Yes! I'm in.
<dmart> cool
<nosse1> eh? what is the default init string from the kernel. isn't it "/sbin/init"... What I try to run /sbin/init manually, it complains about missing runlevel
<ogra> lool, debian/clean is that new ?
 * ogra never heard of it
<dmart> nosse1: init must run as pid=1, so you must type exec /sbin/init -v (not just /sbin/init -v)
<dmart> ...otherwise init tries to be initctl
<dmart> or telinit or something
<dmart> any luck
<dmart> ?
<nosse1> d'oh
<nosse1> thanks
<dmart> no probs
<hrw> nosse1: /sbin/init then /bin/init then /linuxrc iirc
<nosse1> hrw: You asked if I have tried openembedded kernel. Does this imply that I possibly can use a kernel compiled from OE?
<hrw> nosse1: personally I would try that at least
<hrw> nosse1: usually our kernels works with our targets
<nosse1> Yes. Compiling a crossed OE kernel is easier. I just need to find what kernel resources ubuntu requires. I can probably ask on #ubuntu-kernel
<hrw> nosse1: it is probably linux-omap-psp 2.3.32 tree
<ogra> hrw, note that ubuntu userspace often uses kernel features from the ubuntu kernel
<ogra> i.e. OE might not have everything enabled the ubuntu userspace expects to exist
<nosse1> Perhaps it would be easier by looking at the source package of another Cortex-A8 kernel to find these core linux kernel settings
<jaustin> ogra: any advice on how to best get a kernel with the features Ubuntu userpsace expects if the board vendor's kernel isn't mainline? (but is ina git repo)
<ogra> just take the imx51 or dove kernel config
<hrw> ogra: thats a matter of setting.
<ogra> jaustin, well, compare the configs is the best i can recommend
<nosse1> pardon my naivity: Where can I find the imx51 config?
<jaustin> ogra: right, so you're talking config and not features missing from the source?
<hrw> nosse1: in linux-image package for imx51 board
<ogra> jaustin, well, config but also features like apparmor and friends for example
<dmart> Would it be worth diffing the ubuntu versatile config against mainline?  That might be useful to highlight non-platform-specific options turned on for Ubuntu
<jaustin> ogra:  I see. the main issue I ran in to was udev and 2.6.28 - which is why I'm now trying to use 2.6.33
<ogra> ah, yeah udev and kernel go hand in hand
<dmart> My experience is that using a kernel <2.6.31 with lucid is a waste of effort
<ogra> same for other stuff
<ogra> i.e. mountall
<ogra> it expects devtmpfs to exist in lucid
<dmart> You can work around mountall by putting "ignore" entries in fstab, or /dev ... tmpfs (but it's not really worth the work)
<ogra> yeah
<ogra> or by just properly using an initramfs
<ogra> lucids initramfs takes care if devtmpfs doesnt exist
<jaustin> In Karmic I had everything I wanted except pulsaudio with 2.6.28. I got sound using the jaunty udev rules, but pulseaudio never got onboard.
<dmart> I think now /lib/init/fstab has /dev ... devtmpfs,tmpfs (so it will fall back to tmpfs if needed)
<dmart> ogra: is the devtmpfs code in mainline?  I wasn't sure whether that was ubuntu-specific
<ogra> yes
<ogra> its mainline
<dmart> oh, ok
<ogra> but only in .32
<ogra> and later indeed
<ogra> for imx51 we had to backport it
<ogra> speeds up booting significantly
<dmart> did we backport this to .31 for imx51?  I seem to remember traffic about it
<ogra> yes
<dmart> makes sense
<nosse1> In ubuntu, what do you do in initramfs before heading into main boot (apart for loading any required modules)?
<ogra> initializing things like frambuffer, running early udev ... getting your password in case you got any encrypted partionions, setting up dm-raid or LVM etc etc
<nosse1> So I guess you use it on the imx51 target as well then. Thanks
<ogra> there is no ubuntu without initramfs so yes, we use it in imx51 too
<ogra> there are a bunch of packages that rely on initramfs bits
<DanaG> hmm, but how do you get u-boot to USE initramfs?
<hrw> /var/run/dhclient.wlan0.pid: interface name too long (max 27)
<hrw> someone saw: "/var/run/dhclient.wlan0.pid: interface name too long (max 27)" on debian/ubuntu?
<ogra> DanaG, you load it to the appropriate address and attach that address to the bootm command
<hrw> have  a nice rest of day
<ogra> gah, crap
<ogra> u-boot can only fatload from partitioned devices
<ogra> that makes image building trickier :/
<ogra> which is a bit funny since x-loader apparently loads u-boot.bin form that unpatitioned SD
 * ogra will go on with that tomorrow
<nosse1> ogra: I'm having trouble starting qemu with tap using the description on RootfsFromScratch. I'm getting could not configure /dev/net/tun: no virtual network emulation. Perhaps the /etc/qemu-ifup isn't being run?
<nosse1> I'm sorry, I seem to have network problems. I don't know if ogra has answered my Q
<armin76> nosse1: he hasn0t
<armin76> hasn't
<lool> ogra: it's not any different for beagle than for dove?
<lool> Wee!
<lool> x-loader built and is now cross-buildable too
<dcordes> lool, dove ?
<lool> dcordes: mach-dove, the marvell image we output
<lool> to support the soc of the same name
<lool> dcordes: ARMADA
<dcordes> marvell..
<dcordes> I'm looking forward to run ubuntu on my htc hd2
<DanaG> rcn-ee: interesting stuff with the new 33-500-omap kernel.
<DanaG> One: mtd doesn't seem to work.  /dev/mtd stuff doesn't exist.
<DanaG> Another: I sometimes get an oops and a backtrace upon initializing twl4030_usb
<rcn-ee> Hey DanaG, sorry been gone the last two days.. ;)  which 500.X? ;)
<DanaG> linux-image-2.6.32-500-omap, in lucid.
<rcn-ee> yeah, the package has a 500.x number on it.. uname -a might show.. ;)
<DanaG> ah
<rcn-ee> 500.1 broken, 500.2 will boot.. ;)
<DanaG> [    0.000000] Linux version 2.6.33-500-omap (buildd@korlan) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu2) ) #3-Ubuntu Tue Mar 23 20:29:18 UTC 2010
<rcn-ee> humm... crap...
<rcn-ee> DanaG, i submited a patch to ubuntu-kernel for the usb problems. ubuntu would like to first try to have it loaded as an external module.. I'd like to bring it internal.. ;) this patch: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/lucid-ti-omap/annotate/head%3A/patches/beagle/0001-UBUNTU-Config-Enable-musb-ehci-on-beagleboard.patch
<DanaG> unfortunately, I can't figure out how to grab all the output through "screen"
<rcn-ee> use cutecom, it has a log to disk feature..
<rcn-ee> other than that it's not that good, so i'm constantly switching back and forth..
<DanaG> ah, screen -L /dev/ttyUSB0 115200
<DanaG> -L for log.
<DanaG> oh, and something weird: the only place I've seen the gpio-keys input thingy appear and work, is in the Angstrom kernel.
<rcn-ee> hum, must have mis did one of the gpio settings in the config..
<DanaG> www.csc.calpoly.edu/~dgoyette/screenlog.0
<DanaG> weird... last time I rebooted the thing, it gave an oops and hung.
<DanaG> this time it rebooted fine.
<DanaG> anyway, the host sees "device descriptor read error"
<rcn-ee> sorry DanaG, was quickly writing a howto.. with ubuntu's kernel we need to make an initramfs...
<rcn-ee> take a look at: http://elinux.org/Talk:BeagleBoardUbuntu#Conversion_to_Ubuntu_ti-omap_kernel
<DanaG> cool
<rcn-ee> it's a little of a mess at this point... ;)
<rcn-ee> 1. boot with no initrd.. 2. mount fat16 partition (fails) 3. run setup.sh script 4. reboot 5. some things work better..
<rcn-ee> i have a patch for 2. in my tree, but i don't think ubuntu will exept that one.. i think they are planning to generate their own uIntrd's on release... it's just a chicken and egg problem for us developers..
<DanaG> hmm, why does it copy to boot.ini?
<rcn-ee> IGEPv2's boot loader looks for that. .;)
<rcn-ee> I'm hacking on three boards at once.. bx, IGEPv2 and xm..
<DanaG> http://www.csc.calpoly.edu/~dgoyette/screenlog.0.txt
<rcn-ee> yeap that's the musb module...
<DanaG> "unable to read boot.scr
<DanaG> "
<DanaG> weird... u-boot doesn't see the file!
<rcn-ee> i'm still suprised it mounted your sd card... mine didn't like that at all..
#ubuntu-arm 2010-03-25
<DanaG> [   35.623962] musb_hdrc musb_hdrc: musb_init_controller failed with status -19
<DanaG> [   35.643035] last sysfs file: /sys/devices/platform/gpio-keys/input/input0/event0/uevent
<DanaG> er, missed this in the middle:
<DanaG> [   35.639160] Internal error: : 1028 [#1]
<rcn-ee> DanaG, give this one a try, it's my current work in progress.. http://rcn-ee.homeip.net:81/dl/testing/lucid/linux-image-2.6.33-500-omap_2.6.33-500.3_armel.deb
<DanaG> I'm going to be leaving soon, but I'll give it a try later.
<DanaG> Is it possible that the u-boot usbtty is interfering?
<DanaG> ...even though I'm not using it.
<rcn-ee> no problem, i'll be working on a couple things, so just watch the bzr repo i use...  i don't know if that's ready for the c4 board yet...
<rcn-ee> nah it shoudn't...
<GodKa> hello
<rcn-ee> howdy doody
<GodKa> What can i put on my Asus A636
<GodKa> ?
<GodKa> Hi rcn-ee
<rcn-ee> it looks like it's xcale...
<rcn-ee> pxa270, i think that's armv4, which would mean, angstrom or debian...
<GodKa> great
<GodKa> Some ubuntu?
<GodKa> A few years ago i wanted to put some linux on it, but it didn't support gps an wifi ad that sucks
<rcn-ee> ubuntu's lowest minimum requirement was armv5, but that was 9.04... (9.10 requires armv6 and 10.04 is armv7)
<rcn-ee> if you can find a kernel, ubuntu squeeze should run great on it...
<DanaG> Cannot access MTD device /dev/mtd2: No such file or directory
<DanaG> rcn-ee: that's on the test kernel you linked.
<DanaG> All /dev/mtd* are missing.
<nosse1> For some reason I am not capable of starting qemu-system-arm with -net tap support. I followed the instructions on the RootfsFromScratch
<ogra> nosse1, i'm not using any tap devices myself, but i think it helps starting the VM with sudo in that case
<ogra> lool, hmm, could it be that parted dropped support for units other than megabyte ? parted -s test.img mkpart primary fat32 0 67107840B doesnt seem to work anymore and the manpage only talks about megabyte (and gives no info about how to use other units)
<ogra> LANG=C parted -s test.img mkpart primary fat32 0 67108352B
<ogra> Error: The location 67108352B is outside of the device /var/build/omap-image/test.img
<ogra> thats definately not true if the unit would actually be bytes
<ogra> (the partitioned image with MBR is 67108352 so it should leave exactly teh needed space)
<lool> ogra: Remember that the offsets are zero based
<lool> and inclusive
<lool> ogra: So if your file is 67108352 bytes, you need to write up to 67108351B
<ogra> hmm
<ogra> + DISK_END_B=67108352B
<ogra> intresting
<ogra> where does that one byte come from then
<ogra> (i'm using the dove script and try to modify it for omap atm)
<ogra> oh
<ogra> the script devides by 512 ... i'm using mkdosfs -C which uses a blocksize of 1024
<ogra> bah, doesnt pay off to be lazy :/
 * ogra uses dd instead of leaving image creation to mkdosfs
<nosse1> ogra: Using sudo with qemu worked. Thanks.
<nosse1> ogra: However when i start the vmlinuz the kernel log sais "eth: Ethernet addr: xx:xx" and then "eth0: No PHY found"
<nosse1> I have "-net nic,macaddr=xxx -net tap" as options to qemu
<ogra> sorry, but i have not used tun/tap stuff since several years ...
<ogra> (no idea who added it to the wiki or if it works at all)
<nosse1> Well the linux inside qemu assigns macaddr according to my settings, so obviously something is working
<ogra> crap
<ogra> so using the dove script defintely doesnt make MLO/u-boot.bin work
<ogra> lool, did you change any config options in the x-loader package ? i cant make it load u-boot from SD anymore
<lool> ogra: I did not
<lool> The two things which change build flags which I changed: I reworked the -fno-stack-protector passing (but as you can see, it's in the log), I fixed passing of -Bsymbolic-functions, and I also made sure that CFLAGS were passed to HOSTCC
<nosse1> Is there any easy way to make qemu display more than 80x24? A kernel option similar to vga= in x86
<lool> nosse1: Consider connecting over SSH; that will match your local terminals
<nosse1> ok, thanks
<nosse1> apt-get install openssh-server
<nosse1> Argh... Wrong window :D
<lool> ogra: So did you try an older binary from x-loader?
<ogra> lool, no, but it seems to be related to partitioning actually
<ogra> Texas Instruments X-Loader 1.4.3 (Mar 24 2010 - 21:16:42)
<ogra> Reading boot sector
<ogra> Error: reading boot sector
<ogra> Loading u-boot.bin from nand
<ogra> it works if i partition manually but not if i use the dove script
<ogra> sigh
<ogra> now it doesnt work with manual partitioning either :(
<ogra> gah
<ogra> it exclusively needs haeds and sectors
<ogra> lool, do you know of any way to enforce heads and sectors with parted ?
<ogra> i fear i have to resort to fdisk or sfdisk
 * ogra only sees chs for unit printing in parteds manpage
<lool> ogra: I think you can use chs as an unit when creating the partitions
<ogra> hmm, thats a hell lot of math
<ogra> apparently MLO also doesnt work anymore if the partition is >1G
<ogra> hmm, no, actually 800M
<lool> ah I know what I had forgotten yesterday
<lool> Vicious, fat16 support is broken
<lool> So only -F 32 works
<lool> and I had forgotten the bootable flag yesterday
<lool> ogra: I confirmed that x-loader and u-boot from the archive work (at least in qemu-system-arm)
<ogra> lool, yeah, they do, its a partitioning issue
<lool> ogra: Hmm I wonder what the plan is for the beagleboard image?  SD card?
<lool> ogra: Or NAND image?
<lool> ogra: Currently, the x-loader package is built for NAND boot
<lool> actually it seems to be turned on by default, but it attempts reading from NAND, not MMC, odd
<lool> Blank nand/onenand contents, attempting serial boot . . .
<lool> Loading u-boot.bin from nand
<lool> actually problem is: Error: reading boot sector
<lool> Hmm if I pass a NAND file to qemu, it insists from booting from it, even if empty
<rcn-ee> you guys having fun with x-loader? ;)
<rcn-ee> lool, it defaults to nand unless you push one of the keys on boot....
<lool> rcn-ee: is there a way to change that?
<lool> rcn-ee: So I'm trying to get a SD image to work under qemu-maemo-system-arm
<lool> My SD image has MLO and u-boot.bin
<lool> but x-loader never loads u-boot
<lool> In the case where I pass -sd and -mtdblock, it doesn't even load x-loader
<rcn-ee> are you using the omap target under qemu?
<lool> Yes
<lool> well -M beagle
<lool> ARGH
<lool> -m 256 fixed it
<rcn-ee> i'm not sure if that even works...
<lool> the default memory size is just stupid
<lool> Ok, so I solved the -sd + -mtdblock issue wiht -m 256
<rcn-ee> last i heard it working was: http://code.google.com/p/qemu-omap3/
<lool> Now the next one is how to tell qemu to tell x-loader that I want a MMC boot, or how to configure x-loader to default to that
<lool> or how to have x-loader fallback to that
<lool> the last option is probably the best
<lool> rcn-ee: I'm using a newer branch
<lool> rcn-ee: http://maemo.gitorious.org/qemu-maemo/
<lool> rcn-ee: I have it in ppa:lool/ports-dev
<lool> Texas Instruments X-Loader 1.4.3 (Mar 24 2010 - 21:16:42)
<lool> Reading boot sector
<lool> Error: reading boot sector
<lool> Loading u-boot.bin from nand
<lool> It doesn't try MMC
<rcn-ee> ah cool..
<lool> Angstrom's x-loader defaults to loading it from MMC for some reason
<ogra> lool, SD card
<lool> Texas Instruments X-Loader 1.4.2 (Jul 16 2009 - 01:58:04)
<lool> Reading boot sector
<lool> Loading u-boot.bin from mmc
<ogra> lool, thats why i added signGP
<lool> *wow* if I pass -m to a qemu run with -sd alone, it breaks again
<rcn-ee> yeah, on real hardware you defintelly need the signGP part
<ogra> lool, you need to use the MLO binary and the partitioning needs to match to make x-loader load from MMC
<lool> so -sd + -mtdblock + -m => ok, -sd + -m => breaks, -sd + -mtdblock => breaks, -sd + -mtdblock => breaks
<lool> well I've put the same twice
<lool> -sd => ok
<lool> I don't think it's a problem of signature since I can get it to work with different flags
<lool> besides, x-loader *is* loaded, just not u-boot
<lool> even weirder: -sd Angstrom image works with or without -m, only my image requires -m
<lool> Ok, I think my image breaks because it tries reading NAND and that requires -m
<ogra> lool, make sure to do the partitioning of your SD image right
<ogra> x-loader a) requires the boot flag to be set b) needs 255 heads and 63 sectors
<ogra> without a) it will resort to the NAND x-loader (if it exists) without b) you get the bootsector issues
<ogra> thats what i'm struggling with atm trying to build an image
<lool> ogra: As I said, it does get loaded
<ogra> ah, i missed that in the reconnection noise
<ogra> but you have the bootsector issue
<lool> My biggest problem is that our x-loader tries NAND and that either doesn't fallback or breaks qemu
<ogra> that goes away for me if i use 255 heads and 63 sectors during partitioning
<lool> we don't want it to try NAND because we want to boot from MMC, even if NAND boot works
<ogra> are you using MLO ?
<lool> so we need to configure our x-loader for MMC only, no NAND
<lool> ogra: Yes
<ogra> we want to use NAND if u-boot cant be read from MMC
<ogra> so that we have a fallback (in case there is something in NAND)
<ogra> your prob is your bootsector
<ogra> not our MLO
<ogra> i can fully boot from MMC here with our binaries
<lool> ogra: Does it really boot from MMC?
<lool> or does it try NAND?
<lool> You don't know what's in NAND, so you can't be sure it will boot on MMC
<ogra> i know whats in my NAND here
<lool> I'm fine with a x-loader which tries MMC first, but that doesn't appear to be the case of ours
<lool> ogra: You don't know what's in people's NANDs
<ogra> it is for me
<ogra> did you try on a real beagle or only in qemu ?
<lool> No it's QEMU alone
<lool> It might be that QEMU doesn't set the SYS flags properly
<ogra> using this reciepe http://paste.ubuntu.com/397188/ with mmy SD in a real beagle gets me a full MMC boot
<lool> ogra: Are you sure it's not trying to read from NAND?
<ogra> the binaires in NAND on my beagle both have a timestamp from feb 19th ... its very easy to see if it loads the MMC versions or the NAND versions here
<rcn-ee> that's the one i usually recommend, on some weird sd cards, formating as '16' vs '32' helps, but those are rare cards..
<lool> I don't think there's any problem with my "SD card"
<lool> since it does load MLO
<lool> and it starts
<ogra> lool, i'm 100% sure, yes and i have seen the "Error: reading boot sector" if the gemoetry wasnt matching
<lool> my problem is interaction between our MLO and QEMU/emulated hardware
<lool> ogra: That can be triggered by many things
<ogra> well, it uses MMC if i use the above partitioning
<ogra> for both, MLO and u-boot
<ogra> so i'm sure our MLO is correct
<rcn-ee> lool, can you ignore the MLO and just boot with u-boot in qemu? or do you need to simulate exactly?
<ogra> it only falls back to NAND
<lool> rcn-ee: I don't think I can boot u-boot directly, no
<lool> rcn-ee: Unless you know how to achieve that?
<lool> well I could put u-boot.bin as MLO, not sure how that'd work
<lool> rcn-ee: But I'd like qemu to be able to load our Ubuntu images
<rcn-ee> some users have done it, that's why i ask... (you got to really cut down on u-boot size)
<lool> well perhaps the qemu partition checking code is not the same as the MLO one   :-/
<rcn-ee> okay, I was guessing that might be the reason.. it make sense..
<ogra> Texas Instruments X-Loader 1.4.3 (Mar 25 2010 - 09:53:14)
<ogra> Reading boot sector
<ogra> Loading u-boot.bin from mmc
<ogra> U-Boot 2010.03-rc1 (Mar 24 2010 - 15:50:56)
<ogra> OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max clock-720Mhz
<lool> http://paste.ubuntu.com/401137/
<ogra> lool, ^^^^
<lool> ogra: ok, thanks
<ogra> (i recompiled x-loader today, but its identical to the archive version (built from package)
<rcn-ee> lool, found this.. http://www.omappedia.org/wiki/E-MMC_boot#eMMC_RAW_boot_Procedure_for_ZOOM3 SYS_BOOT defines what x-loader boots from first..
<rcn-ee> it's zoom, so not 100% the same as beagle..
<rcn-ee> crap, nevermind, that's just a hardware config boot option....
<ogra> Texas Instruments X-Loader 1.4.3 (Mar 24 2010 - 21:16:42)
<ogra> Reading boot sector
<ogra> Loading u-boot.bin from mmc
<ogra> U-Boot 2010.03-rc1 (Mar 24 2010 - 15:50:56)
<ogra> OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max clock-720Mhz
<ogra> OMAP3 Beagle board + LPDDR/NAND
<ogra> here another one with both versions from the packages
<lool> rcn-ee: Well that's relevant
<lool> rcn-ee: I'm personally more suspicious that QEMU doesn't set SYS properly than x-loader misparsing my part data
<rcn-ee> kinda, it'll help find the boot variable in x-loader..
<lool> I was trying to write that to SD to actualy try
<ogra> lool, x-loader seems to be very fragile wrt partitioning
<ogra> which is very odd
<rcn-ee> i wouldn't be suprised, x-loader needs a specific partition setup, any variations and it fails...
<ogra> i'm struggling with image building on exactly that problem atm
<ogra> rcn-ee, exactly what i found here
<ogra> and it needs to be copied on the filesystem as the vers first file as well
<ogra> *very
<rcn-ee> yeap... that's one reason i've always ignored it on the wiki's...  the factory version is usually good, so no reason to upgrade.. ;)
<ogra> else it wont load
<ogra> well, i have seen beagles with empty NAND
<ogra> in which case you *need* a working MLO
<rcn-ee> yeap, that does happen...
<rcn-ee> (my xm is empty)
<ogra> and i also  want our images to install the same MLO into NAND that we just used to boot the image
<ogra> i.e. i want to be sure that NAND has something that works
<rcn-ee> that makes sense...  it would almost be easier to have a seperate recovery image..
<ogra> which is why i build -xloader.bin and MLO in the package
<ogra> usually an ubuntu image should be used for recovery
<ogra> we use that scheme in x86 so i want to use it on arm as well
<rcn-ee> one image for all.. but it sounds like you got MLO and u-boot working.. omap on qemu is still a virgin setup...
<rcn-ee> the one case that problems might arrise, is when a overo or igepv2 user boots with that image.. i don't remember if MLO detects hardware, or is hardware specific...
<ogra> MLO is definately HW specific
<lool> ogra: i don't think it's a good idea to install our MLO in NAND
<ogra> lool, x-loader.bin should go to NAND
<ogra> not MLO :)
<lool> 13:39 < ogra> and i also  want our images to install the same MLO into NAND  that we just used to boot the image
<lool> I don't think that's a good idea
<ogra> indeed
<ogra> the x-loader.bin should go to NAND but its the same binary after all, MLO just adds a header
<lool> (I don't think we need to touch people's NAND unless that's what they want explicitly)
<lool> ogra: I'm not convinced we want to install a x-loader which defaults to MMC in NAND
<lool> I don't think we need touch their x-loader at all in fact; there are multiple nice mechanisms to boot from SD on beagle already: boot.scr, or user button
<lool> ogra: You might want to build two x-loaders then: one which loads from MMC by default and one which loads from NAND by default
<rcn-ee> i know when a user picks up one from digikey the board will boot from x-loader into a working u-boot enabled for boot.scr...  it's just some of the early xm's and demo units don't have nand setup...
<ogra> or the ones you bricked :)
<rcn-ee> exactly..  or the ones with broken nand... ( i got one here)
<ogra> yeah, i trashed my revB many times already
<rcn-ee> laughs, i have a user who wants to fit a 500mb xfce karmic image in 128 mb of nand..... ;)
<ogra> compress harder :)
<amitk> ogra: how close are we to an image? I am trying to decide if we should start compiling in all the OMAP drivers into the kernel till we get the image going...
<rcn-ee> that's going to be my response.. and strip everything..
<ogra> amitk, note very close yet, i'm struggling with the bootloader restrictions for partitioning ... but i hope to have that solved latest tomorrow
<ogra> amitk, if we want to use the kernel for more than beagle i'd suggest being as modular as you can
<ogra> if we dont care for other HW but beagle for now, go for it
<rcn-ee> i'll keep testing with all my boards, i know a user with an overo that should be able to verify th eimages too..
<amitk> ogra: I'd like other OMAP3 HW to just run on the same kernel (because it can!). But we can always go back to being modular once the images work
<ogra> amitk, can we ? (does time permit)
<ogra> we'Re late in the cycle and the kernel didnt even see much testing yet
<ogra> i expect a ton of bugs to show up in the next weeks
<ogra> do you expect to have time for debugging module issue additionally ?
<lool> rcn-ee: Do you know how Angstrom builds the x-loader for their image?
<lool> cause that one works
<lool> it tries MMC and succeeds
<ogra> lool, its the same upstream so it must be a config change they do, ask _koen_ in #beagle
<rcn-ee> cool... they might have one or two external patches.
<ogra> ah
<ogra> i thought they use sarkoman's branch plainly
<rcn-ee> just one, but only a name thing...  recipie is here: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/x-load/x-load_git.bb
<rcn-ee> they are using shaid: dee19371019ef67cb1f6491ef91791b12feda3f2  it might not be top of tree...
<rcn-ee> they are also using their special 4.3.1 compiler...
<ogra> hrm
<ogra> so i have the script using fdisk up to a point that u-boot gets properly loaded but MLO doesnt
<lool> I tried using parted, but it's not accepting the high-head and high-sector values I'm passing  :-/
<ogra> well, i resorted to fdisk for now
<ogra> but MLO isnt behaving
<ogra> u-boot and kernel are though
<hrw> ogra: omap3 card partitioning?
<ogra> image partitioning
<hrw> ogra: in OE we have a script for it
<ogra> card partitioning is trivial :)
<hrw> sure
<plars> ogra: does sfdisk work for it?
<ogra> might
<plars> I've used that in the past for some automated partitioning, however I was using real disks at the time, so I'm not sure off the top of my head
<plars> seems that if nothing else, you could use it on a loopback device
<ogra> no, cant
<ogra> thats the big prob with our image builders :)
<ogra> no root
<ogra> being able to loop mount would make the whole task trivial
<ogra> the way you have to do it is to create an image, partition that, and then dd the partition contents in place
 * ogra curses ... 
<ogra> so using dd with a blocksize always gets the sizes wrong ... using dd with a blocksize of 1 byte gets everything right but takes hours
<ogra> i wonder if we cant just dd the MBR in front of the image instead
<ogra> bah
<ogra> now i have one script that makes MLO work but fails with a bootsector error to load u-boot and one script that uses MLO from NAND but loads u-boot fine
<ogra> sigh
<ogra> god, thats annoying
<nosse1> I'm having some strange problems with networking in qemu. Networking is apparently fine in qemu, i.e. apt-get and such works from the guest ubuntu. I start a ssh-server in guest and I'm able to connect and log into it from the host. However I cannot get any output!
<nosse1> tcpdump on both host and guest reveals that packages are being sent from host to guest, but not the other way around
<nosse1> If I kill the ssh session on the guest, all the ssh's output arrives on the host ssh client
<ogra> lool, why did we always do these complicated image buildscripts, cat'ing partition images to an mbr.img file that holds the mbr is so much less effort
<ogra> especially since you have the sizes available from the files
<nosse1> Is there anyone else that have struggled with ssh connection into a qemu arm versatile session? I think I have wasted a couple of hours trying to figure it out.
<nosse1> The network is fine, so it's something particular which happens with the ssh server on the guest.
<nosse1> (I'm running lucid ubuntu-minimal from rootstock on the guest)
 * nosse1 gives up his endeavour to have more than 80x24 in qemu
<lool> ogra: binary blobs versus code?
<ogra> lool, binary blobs ?
<ogra> dd if=/dev/zero of=mbr.img bs=1 count=512
<ogra> parted -s mbr.img mklabel msdos
<ogra> cat $IMAGE >>mbr.img
<ogra> something like that
<nosse1> I think I have found a bug, but I dont know if its something that needs fixing
<ogra> file it :)
<nosse1> If you make a lucid ubuntu-minimal image, run it with qemu and install openssh-server, ssh to localhost does not work
<nosse1> The question is if this is a ubuntu issue or a qemu specific "feature"
<nosse1> OK, the bug is recreated from scratch using only rootstock and qemu
<nosse1> Where should I file it? To what package/module?
<ogra> rootstock for now, i'll check where it actually fits later
<nosse1> Quick question before I file: Is rootstock limited to ARM targets?
<ogra> currently it is
<amitk> ogra: how is it going?
<ogra> amitk, bad
<ogra> amitk, the CHS requirement for fat partitions is biting me badly
<lool> Hmpf
<amitk> right, the 255 blah blah
<ogra> yeah
<ogra> doing that for images is very painful
<ogra> but i'll figure it out
<ogra> *somehow*
<amitk> you mean you can't partition automatically?
<ogra> i can partition, but either x-loader or u-boot dont get loaded
<ogra> worst case i'll just assume that the NAND setup just works, but i'D prefer to not do that
<nosse1> I'm running a patched version of rootstock. asac pointed me to a patch a couple of days ago. The diff I have sais 31_30.diff.
<nosse1> What is that? I should put a reference to it in the bugreport I think
<ogra> thats to enable lucid on a karmic build system
<nosse1> "Version 31 of the karmic version of rootstock"?
<nosse1> You will understand that?
<ogra> nosse1, yes :)
<nosse1> ogra, thanks
<nosse1> Submitted
<ogra> thnaks
#ubuntu-arm 2010-03-26
<crimsun> so, Dove X0 should be good to go WRT default audio settings. I've uploaded both alsa-utils and pulseaudio for that.
<lool> Someone tried the openoffice binary packages?
<lool> Would be nice to confirm the fix and close this awful bug  :-)
<ogra> lool, did you see my question from yesterday ?
<ogra> (why dont we cat the partition/mbr files together butu do complex math and an additional image instead ?)
<ogra> *but
<lool> ogra: You mean why don't we release the individual bits?
<lool> instead of an SD card image?
<lool> or why don't we have blobs in the debian-cd/cdimage trees?
<ogra> no, in our debian-cd scripts we create an empty image, add an mbr, do complex math to dd the contents into it etc
<ogra> dd if=/dev/zero of=mbr.img bs=1 count=512
<ogra> parted -s mbr.img mklabel msdos
<ogra> cat $IMAGE >>mbr.img
<ogra> etc etc
<ogra> why dont we do it like that instead and use the filesizes for the values we need
<ogra> way less complex
<lool> ogra: Because you don't know which size your partition is actually going to have
<ogra> i.e. append each partition image we create to the full image and "mv mbr.img resulting.img" in the end
<lool> We need to create partitions before we know for sure which size they'll have
<ogra> sure i do, at least if i can use byte values like parted does
<ogra> well, cat'ing definately works here
<lool> You can specify a partition size in bytes, but its size wont be the one you passed...
<ogra> hmm
<ogra> you mean because of block sizes ?
<ogra> vs byte size
<lool> No
<lool> sector size, and in your case you have additional constraints due to chs addressing
<ogra> yes, i wasnt talking about my current case though ... just in general
<lool> (we have other constraints in other cases, for instance the FIS needs to have a size which is a multiple of the flash block size 0x2000 IIRC)
<lool> ogra: I don't think there's any easy case
<ogra> right, we could still fill up the images with ueros though
<ogra> *zeros
<ogra> and then glue them together
<lool> ogra: which is what we do by dd-ing them in place
<ogra> though it doesnt make it easier ...
<ogra> right, the constraints somehow make my point moot :)
<ogra> i'm wondering why i dont see any probs with that here though
<lool> Also, tools like parted or other disk utilities don't like creating partitions which go beyond the device boundaries
<ogra> but probably because i dont read to the end of the partition
<lool> so we'd have to create the partitions with the data in place already anyway
<lool> It's just becaue your current file sizes happen to work and you're not trying to write at the end of partitions
<ogra> right
<ogra> thanks for clearifying
<lool> I think the current approach is proven solid, even if it's a bit complex; I went through great length to put a bunch of sanity checks in place which prevent us from doing anything nasty, and I think it's the right way to do it
<ogra> sadly its only solid on the build server, as soon as i run it locally i get size probs
<lool> However you'll have to be creative because parted doesn't seem to allow enforcing the chs geometry
<ogra> i'm not sure why
<ogra> well, sfdisk does allow it
<ogra> so i'll likely resort to fdisk or sfdisk
<lool> I would prefer if we'd keep their usage minimal though
<ogra> or worst care just rely on u-boot being in NAND ...
<ogra> *case
<lool> for many reasons: the checks are currently written using parted which is the canonical tool for partitioning which we use in other circunstances, I would prefer if we kept the number of tools to a minimum, and this puts higher constraints on the image building host and developer machines building images
<ogra> sure, but partwed doesnt give mee the functionallity i need
<ogra> i need something that works ... *now*
<ogra> so my options are small
<lool> I know, but for instance you could just create one partition with fdisk and use parted for the rest
<lool> that would allow keeping the same logic everywhere else
<lool> Such as partition size checks
<lool> Cause parted can actually read the partition table just fine, just not create it
<lool> Or you could just dd the partition info just like we dd the partition type for redboot fis (non-fs data)
<ogra> indeed
<ogra> i didnt plan to use fdisk all over the place :)
<ogra> ha !
<ogra> that worked
<ogra> heh, intresting, the SD i dd the image to boots fine, but my x86 machine cant mount the SD anymore
<hrw> morning
<lool> morning
<amitk> ogra: yes, two reasons why you won't see anything on the display on omap - I'm still merging the DSS2 stack from 2.6.34-rc2 back into our tree and the drivers are modules.
<ogra> ah, sad
<ogra> i was hoping to have a live image ready for next week
<ogra> i also see that compcache only assigns 60M
<ogra> i think we should raise that
<amitk> ogra: try the kernel on people.canonical.com:~/amitk/ti/zImage
<ogra> does that have the modules builtin ?
<amitk> ogra: yes, its the first compile after porting the dss2 stack back and compiled-in
<amitk> 51 patches
 * ogra downloads
<ogra> i hope the modules in initramfs will still work
<amitk> ogra: no guarantees, I can start compile for a temp debian package if this improves things
<ogra> [   35.326751] FAT: codepage cp437 not found
<ogra> [   36.601043] FAT: codepage cp437 not found
<ogra> over and over
<ogra> and nothing on screen
<amitk> *sigh*
<amitk> I'll compile a debian package
<amitk> ogra: or perhaps you could try w/o the initramfs
<ogra> well, it should show any output before it goes to initramfs
<ogra> but the screen just shuts down
<amitk> so *something* in the DSS2 stack is working :)
<ogra> mount: mounting /dev/mmcblk0p1 on /cdrom failed: Invalid argument
<ogra> modprobe: FATAL: Could not load [   67.495635] FAT: codepage cp437 not found
<ogra> /lib/modules/2.6.33/modules.dep: No such file or directory
<ogra> well, it behaves like with the archive kernel
<amitk> ogra: that could be missing udebs
<ogra> on a live image ?
<amitk> hmm, no
<ogra> its missing modules that are in your build but not in the casper initramfs from the archive kernel
<lool> ogra: Do you have an initramfs with nls_cp437.ko in it?
<lool> ogra: It might be worth checking whether we put any codepage in the kernel for kernels which are used with FAT images
<ogra> lool, apparently not
<ogra> well, i do, but amitk's kernel looks for a different modules dir
<amitk> ogra: new 500.3 debs on people
<ogra> hmm, thanks though it will be tricky to build a livefs with them
<amitk> ogra: this is a problem with the casper initramfs, right?
<ogra> well, it would also be with any other initramfs
<ogra> /lib/modules/2.6.33/modules.dep: No such file or directory
<ogra> (initramfs) ls /lib/modules/
<ogra> 2.6.33-500-omap
<ogra> amitk, :(
<ogra> amitk, http://paste.ubuntu.com/401821/
<ogra> amitk, doesnt look good
<amitk> ogra: archive kernel?
<ogra> amitk, nope
<ogra> http://people.canonical.com/~amitk/ti/linux-image-2.6.33-500-omap_2.6.33-500.3_armel.deb
<ogra> do you have unionfs in that package ?
<amitk> ogra: yes
 * ogra tries that instead
<ogra> urgh
<ogra> casper dropped unionfs support
<ogra> only unionfs-fuse is supported
 * ogra curses
<amitk> we're trouble for M :)
<amitk> in trouble
<ogra> oh, no, i just didnt see it
<ogra> its there
<ogra> i thought aufs was about to go upstream
<amitk> ogra: aufs was rejected from upstream a year ago
<amitk> forever
<amitk> upstream is working on a union mount solution, but it isn't ready yet
<ogra> ah, still
<ogra> i thought that was dropped in favour of including aufs
<ogra> mount: mounting unionfs on /root failed: No such device
<ogra> unionfs mount failed
<ogra> (initramfs) cat /proc/modules |grep union
<ogra> (initramfs)
<ogra> hmm
<amitk> 2.6.33 has now changed API so that aufs doesn't even compile w/o a hack
<ogra> i dont have a unionfs module :/
<ogra> (initramfs) ls /lib/modules/2.6.33-500-omap/kernel/fs/
<ogra> configfs    nls         squashfs    nfs_common  reiserfs    exportfs
<ogra> nfs         lockd       udf         jfs         isofs       xfs
 * ogra checks the chroot he rolled the initrd in
<ogra> nope
<ogra> hmm, shouldnt that be in the ubuntu subdir ? seems the whole dir is missing
<ogra> ah, no, its there
<ogra> but only compcache in it
<amitk> ogra: sigh, sorry, I forgot to add that commit in this kernel
<amitk> it is on another branch of my git tree
<ogra> ah
<amitk> ogra: so what happens with the archive kernel?
<amitk> wrt aufs
<ogra> hrm, i didnt have a squashfs ready when i tried it last, one sec, i'll test again
<ogra> amitk, same breakage
<asac> bug 417009
<ubot4`> Launchpad bug 417009 in openoffice.org (Ubuntu Karmic) (and 4 other projects) "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic (affects: 1)" [Low,In progress] https://launchpad.net/bugs/417009
<asac> bug 537356
<ubot4`> Launchpad bug 537356 in webservice-office-zoho (Ubuntu Lucid) (and 3 other projects) "application menu entries dont do anything (affects: 2)" [High,Triaged] https://launchpad.net/bugs/537356
<amitk> ogra: ok, i'll look at the oops
<amitk> ogra: could you file the bug please?
<ogra> hrm, the serial console behaves very weird with the archive kernel
<amitk> ogra: freezes?
<ogra> yeah
<ogra> i get the busybox shell but cant type anything
<amitk> ogra: huh, never saw that
<ogra> and it looks like that http://paste.ubuntu.com/401839/
<ogra> looks like it adds tabs on the go
<amitk> I don't see that
<amitk> do you have any HW/SW flow control enabled in minicom?
<amitk> if so, disable it
<ogra> no, and it works fine with your kernel
<amitk> no changes in my kernel except new DSS2 patches
<ogra> strange
<abdalla_> asac: Hello, Are you there?
<ogra> amitk, well, different toolchain
<amitk> ogra: huh?
<ogra> yours is codesourcery
<asac> bug 519897
<ubot4`> Launchpad bug 519897 in squid (Ubuntu Lucid) (and 1 other project) "[armel] squid FTBFS: cf_gen Segmentation fault (affects: 1)" [Medium,Fix released] https://launchpad.net/bugs/519897
<asac> abdalla_: busy atm. ping me in 1h+
<asac> sorry.
<ogra> asac, i think i'll not MIR x-loader and u-boot for now, if we can assume they are preinstalled in NAND and build out images accordingly they can stay in universe for now
<ogra> s/out/our/
<asac> bug 541399
<asac> ogra: ok
<ubot4`> Launchpad bug 541399 in linux-mvl-dove (Ubuntu) "netboot image fails to boot. (affects: 1)" [Medium,New] https://launchpad.net/bugs/541399
<asac> bug 537356
<ubot4`> Launchpad bug 537356 in webservice-office-zoho (Ubuntu Lucid) (and 3 other projects) "application menu entries dont do anything (affects: 2)" [High,Triaged] https://launchpad.net/bugs/537356
<asac> bug 537083
<ubot4`> Launchpad bug 537083 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "Suspend no longer works after updating to 2.6.31-605.9 kernel (affects: 2)" [High,Fix released] https://launchpad.net/bugs/537083
<asac> bug 537356
<ogra> asac, bug 457878 is actually fixed in git
<ubot4`> Launchpad bug 537356 in webservice-office-zoho (Ubuntu Lucid) (and 3 other projects) "application menu entries dont do anything (affects: 2)" [High,Triaged] https://launchpad.net/bugs/537356
<ubot4`> Launchpad bug 457878 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "imx51 on board ethernet plug/unplug events not detected (affects: 2)" [Medium,In progress] https://launchpad.net/bugs/457878
<ogra> (pending upload)
<asac> bug 540477
<ubot4`> Launchpad bug 540477 in xorg-server (Ubuntu) "X restarted, but no .crash file (dup-of: 540256)" [Undecided,New] https://launchpad.net/bugs/540477
<ubot4`> Launchpad bug 540256 in upstart (Ubuntu) (and 1 other project) "enter kills X when booting Live CD or w/cryptsetup with plymouth text plugin (affects: 7) (dups: 3)" [Critical,Fix released] https://launchpad.net/bugs/540256
<asac> bug 515023
<ubot4`> Launchpad bug 515023 in linux (Ubuntu) "ATA pass-through commands preventing external HDD to be mounted (affects: 10) (dups: 1)" [Undecided,Confirmed] https://launchpad.net/bugs/515023
<asac> bug 528524
<ubot4`> Launchpad bug 528524 in totem (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps on dove (affects: 3)" [High,Invalid] https://launchpad.net/bugs/528524
<ogra> asac, bug 548924
<ubot4`> Launchpad bug 548924 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "aufs broken in ti-omap kernel (affects: 1)" [Undecided,New] https://launchpad.net/bugs/548924
<ogra> amitk, want that assigned ?
<amitk> ogra: yes please
<ogra> done
<ogra> amitk, is there a bug about the DSS2 open anywhere ?
<amitk> ogra: no, it will go in w/o the bug
<ogra> i guessed so, but asac wants something to track status
<awolfson> lool, now it works withe the command line from wiki
<awolfson> lool, with -hdb
<Jeff91> howdy all, so I just obtained and htc tilt 8925 and I am interested in running ubuntu arm on it. suggestions on where I should start?
<lool> awolfson: You can use -hda flag with any filename; are you saying that if you try with -hdb it works, and -hda it doesn't?
<hrw> ogra: omap3 allows you to prepare sd card which will flash xloader and uboot into nand on board without them
<hrw> thats how I got bug2.0 running from being not programmed at factory
<awolfson> lool, It did not work for me first time. I will try again
<awolfson> lool, I tried procedure for QEMU from wiki with hda again - it worked that time
<prpplague> davidm: alive today?
<lool> awolfson: Ok; just bad luck first time I guess
<Martyn> I got in a tegra board today
<Martyn> time from getting the board, to booting Karmic (then Lucid..)    1 hour
<Martyn> can't wait to see the official nVidia installer
<rcn-ee> cool Martyn, so what does nVidia give you with the kit?
<Martyn> rcn-ee : Well, the tegra 250, 1Gb RAM (800MB available after video ram is allocated), WiFi, Bluetooth, 3 USB, 1 debug USB, a serial/debug breakout board, MMC slot, eMMC card slot, SIM card slot, two compact PCI-e (miniPCI) slots, VGA port, HDMI port...
<Martyn> full SDK available, Windows 6.5 (and supposedly 7) images available, an android image based on android 2.2, and an empty promise to have an Ubuntu image for download
<Martyn> (you hit the website and find there is no ubuntu image ready yet)
<rcn-ee> those specs sound sweet.. they are probally waiting till closer to the release..  i was looking at their dev site, thinking it would be a nice addition to my arm farm..
<Martyn> rcn-ee : Apply for one
<Martyn> The dev boards are one per company, $400
<Martyn> useful and quite powerful little thing .. 1Ghz dual core
<rcn-ee> ouch, was hoping they'd be less... (my order for a touch book just went thru, so i'll have to wait a month or so)
<Martyn> first they have to accept your app :)
<rcn-ee> true...  and they might not particularly like the fact, I'll start benching them against 4 omap boards...
<Martyn> c*nod*
<Martyn> have you gotten the omap4430 eval board yet?
<rcn-ee> i wish...  I've been bugging my TI contacts for the last 6 months for that board.. ;)
<rcn-ee> i have one of the early XM proto's so as soon as i get my IGEPv2 installed into my gcc test farm, I'm going to see how far that goes.. (Single Core 800Mhz-1.2Ghz range)
<Martyn> I got mine three weeks ago, and let me tell you .. the tegra2 runs rings around it
<rcn-ee> i bet, dual core, 1Gb of memory and real pheripherals..
#ubuntu-arm 2010-03-27
<Martyn> Yep
<Martyn> Well, the 4430 is also dual core .. but the addition of mini PCI-e is awesome
<rcn-ee> and lets not forget the graphics, do they provide the same type of binary blob as in the x86 world, so it works with the latest kernel and xorg?
<rcn-ee> crap, really should have builtin my usb driver for net install..
<Martyn> no
<Martyn> the nVidia driver is not quite so clean
<armin76> NCommander: suihkulokki: zumbi: lool: http://bit.ly/cRN5ta <- about tegra2 in case you're interested
<armin76> ssvb: ^
<ssvb> armin76: Thanks, interesting, though it's a bit sad that they decided not to include NEON. On some tasks like for example video transcoding, NEON can provide a huge help, and it has nothing to do with floating point.
<ssvb> armin76: they probably want to offload all this stuff to some dedicated HW accelerators, but the question is how well are they going to be supported in linux
<armin76> ssvb: well, you've read what they've said about why neon is missing
<ssvb> armin76: yes, and it did not sound convincing
<armin76> ok :)
<armin76> ssvb: btw, if you have any test, i'm happy to do it :)
<suihkulokki> armin76: dual-core cortex-a9 - does it survive ltp pthread stress tests? :)
<armin76> suihkulokki: gimme link and i'll tel you
<armin76> tell*
<suihkulokki> armin76: apt-get install ltp
<armin76> lol
<armin76> apt-get install ltp
<armin76> -bash: apt-get: command not found
<armin76> :P
<ssvb> armin76: 'emerge -pv ltp' :-)
<armin76> yep :P
<armin76> suihkulokki: what command should i use?
<suihkulokki> armin76: all the pth* and mmap*, I think you can select them from the menu too
<ogra_cmpc> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/20100327/
<ogra_cmpc> now we only need a kernel that actually boots for OMAP :)
<rcn-ee> cool ogra!
<ogra_cmpc> to sad it doesnt boot though
<ogra_cmpc> DSS2 patches still missing and aufs is broken .... but we'll get there
<rcn-ee> it should boot... is it based off the orignal 500 kernel?
<rcn-ee> (dl'ing)
<rcn-ee> or wait, does it stop at 'Uncompressing... "?
<ogra_cmpc> no, it stops when trying to mount the squashfs
<ogra_cmpc> but you wont see that since the output defaults to framebuffer (which stays dark without DSS2)
<rcn-ee> okay, differenet bug effecting me this morning.. ;)
<ogra_cmpc> the live image needs any kind of working union filesystem
<ogra_cmpc> unionfs isnt enabled in the current kernel build and aufs segfaults ...
<ogra_cmpc> so there is no way to boot the image atm
<ogra_cmpc> but we'll get there
<ogra_cmpc> next kernel upload should make it work
<rcn-ee> yeah, DSS2 still needs this enabled for the beagle http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/lucid-ti-omap/annotate/head%3A/patches/beagle/002-beagle-dss2.diff  (and it needs to be tweaked for 2.6.34-rc2's dss2 patches amit pulled in)
<ogra_cmpc> right, he is working on that
<ogra_cmpc> we'll have alternate server images soon, these dont need union filesystems and should boot
<ogra_cmpc> my main focus was on the live image for now, server is next
<rcn-ee> okay, sounds right...  Is there  a good way to resync the download without pulling 500mb every new upload?
<ogra_cmpc> use zsync
<ogra_cmpc> there is a zsync file on the download page
<rcn-ee> okay, thanks i'll look into zsync..
<Martyn> I was -so- picked over by airport security today.   I have both the OMAP44xx board and the tegra board in my baggage.  They insisted in looking through _everything_
<armin76> in your babbage? :D
<Martyn> I think one of the ribbon cables to the OMAP4 board was damaged ... so I had a supervisor -sign- that they took it out of a protective case and that they are responsible.
<Martyn> It's a slow day a the airport, I think they were bored and wanted to search stuff
<rcn-ee> hey ogra, not sure if you subscript to the beagle group, but koen posted a new MLO/U-boot combo, so every board needs to be updated.. http://groups.google.com/group/beagleboard/browse_thread/thread/110b417a0ec7b03d
<ogra_cmpc> ah, thanks, i'll look into it next week
<Martyn> rcn-ee : There's also a new release of UEFI for beagle from last week as well
<Martyn> we've been testing it @ Smooth-Stone .. it's not bad.
<Martyn> All this week, I'm looking at polishing the kexec support in the ARM kernel, and trying for a 'soft' bootloader based on a kernel
<rcn-ee> from what i've seen the idea looks promising...  but we still have a lot of things u-boot set's up for the kenrel (ehci power)
<Martyn> rcn-ee : Yep, this is why I'm working on a kernel based bootloader
<Martyn> that way you can get all the drivers up, and use a kernel to boot -another- kernel in a more generic fashion
<Martyn> with a configuration file present in an ext2/3/4, or fat/vfat filesystem (along with boot kernel and ramdisk)
<ogra_cmpc> well, *if* kexec works
<Martyn> ogra_cmpc : I'm ---so--- close
<rcn-ee> kinda sounds like device tree's. ;)
<Martyn> rcn-ee : I'm working with Grant .. yea
<ogra_cmpc> Martyn, well, our kexec experiments in ludic (at least for the supported kerenls) broke suspend/resume
<ogra_cmpc> *lucid
 * ogra_cmpc goe afk doing weekendish stuff
<Martyn> but I have the code working now .. testing it on OMAP3, OMAP4, i.mx51/515, dove, tegra2 and other arm v7 processors I can get my hands on
<Martyn> ogra_cmpc : Have a good weekend :)
<Martyn> ogra_cmpc : Yeah, I came across that early.  The problem was with the way kexec blows over some registers .. I added a patch that saves the registers first.
<Martyn> ogra_cmpc : I'm going to submit the patch to arm-kernel list in about two weeks
<Martyn> and I expect this work to be relevant to lucid+1
<Martyn> (next UDS :) )
<Martyn> re
<Martyn> airport wifi FTL
<lool> armin76: interesting, thanks
<NCommander> lool: just got a set of git emails yesterday on pselect support landing on trunk
<DanaG> rcn-ee: you around?  I tried the Lucid stuff, and found it doesn't seem to handle MTD at all.
<DanaG> That is, the in-repo kernel.
<rcn-ee> DanaG, yeap, i think i fixed that one.. (cat /proc/mtd gives the devices)  CONFIG_MTD_NAND_OMAP2 needs to be builtin...
<DanaG> I also got nonworking USB (both EHCI and musb).
<rcn-ee> yeap, that also requires 3 modules to be builtin... i sent an email to ubuntu's kernel-team with a patch for that...
<rcn-ee> fingers crossed, amit will commit the change later this week https://lists.ubuntu.com/archives/kernel-team/2010-March/009484.html
<DanaG> What's new between v2.6.33-dl.1/ and  v2.6.33.1-dl4/, in a nutshell?  (don't want to read however many hundreds of git commits =Ã¾ )
<rcn-ee> DanaG, some good news: we have a netbook image.. (although it doesn't boot) http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/
<DanaG> cool, though.
<rcn-ee> in a nut shell, i'm trying to figure out why .1 isn't booting on Squeeze & lucid...
<rcn-ee> Cross Compiled with 4.3.1, 4.4.1 works... Native built in lucid works (uImage)... But the Squeeze and Lucid Deb packages all fail at boot at uncompressing...
<DanaG> I'm also wondering about that specialcomp.com LCD board... 480x272 (or whatever the resolution was) doesn't seem to already be in the kernel.
<rcn-ee> i think .1-d5 fixed it.. but the beagle won't finish that deb package for another 4 hours..
<rcn-ee> Cool, never heard of their lcd...
<DanaG> I've also heard of some other companies having bigger LCDs.
<rcn-ee> someone would have to implement that..  I haven't connected any lcd thru the lcd interface..
<rcn-ee> (just hdmi/dvi connected ones)
<rcn-ee> oh, the other weird thing... the lenny deb package (built with 4.3.x) for .1-dx works just fine, running it on one beagle.. it defintelly looks like a 4.4.x native bug..
<DanaG> oh yeah, and I tried suspend on the beagle... it suspended, but didn't seem to give any way to wake it up. =Ã¾
<rcn-ee> yeah, not sure what you could wake it up with.. most perhiperals need power from the twlxxxx chip which the kernel and u-boot setup...
<DanaG> That 3-port-hub-with-ethernet is nice -- in Windows on my host system, it can USB-wake the host.
<DanaG> hmm, are audio and/or midi gadget enabled now?
<rcn-ee> audio output from a wave file worked when i tested it, but all the gadget stuff relies on the usb modules being builtin first..
<DanaG> does it work to keep g_ether as a module?
<DanaG> And can you load more than one gadget-type driver (such as g_ether and g_audio) simultaneously?
<rcn-ee> it's possible, but once you do that on boards with only the otg interface, your stuck with using an mmc card as rootfs...
<rcn-ee> It's what they do in Angstrom, I've gone in the oposite direction with my debian/ubuntu kernel's as i have the rootfs on a big usb harddrive...
<DanaG> hmm, I'm also curious whether gadget audio can do multichannel.
<DanaG> I have a USB surround-sound card that goes all crackly-sputtery in Windows... so I'd like to be able to use the beagleboard as an intermediary.
<DanaG> windows talks to beagleboard as USB sound card... and then beagleboard talks to real sound card.
<DanaG> hmm, so does -1-dl3 work?
<rcn-ee> nope, thats the one that fails at decompression..
<rcn-ee> i think i solved it in .1-dl5, it should be done in 4 hours..
<rcn-ee> just watch: http://rcn-ee.homeip.net:81/dl/farm/log/BUILDING-2.6.33.1-dl5_1.0-lucid.txt
<rcn-ee> i tested a uimage and modules builtin a chroot for that and it worked on lucid, so the deb package variation of it shoudl work...
<DanaG> Dec 31 16:12:08 beagleboard NetworkManager: <WARN>  device_creator(): /sys/devices/platform/musb_hdrc/gadget/net/usb0: couldn't determine device driver; ignoring...
<DanaG> hmm, it seems networkmanager doesn't like usb0.  Can't use networkmanager to make the shared-out network.
<DanaG> linux-image-2.6.33-500-omap will be upgraded from version 2.6.33-500.3 to version 2.6.33-500.3.
<DanaG> weird.
#ubuntu-arm 2010-03-28
<DanaG> weird... now the beagleboard isn't getting an IP address.
<DanaG> ah... a pegasus thingy works, yet asix doesn't, for some reason.
<DanaG> weird... why would asix suddenly fail to transmit and receive?
<DanaG> Class driver suspend failed for cpu0
<DanaG> still getting that.
<DanaG> ARGH
<DanaG> I haven't yet seen one kernel consistently suspend (nevermind resuming).
<DanaG> rcn-ee: what timezone are you in?
<DanaG> the omap kernels (all of them) refuse to suspend. :(
<DanaG> so... any time I try to suspend, it fails... and loses track of all USB devices.
<rcn-ee> DanaG, US Central time. ;)  But i just got back from a bonfire...
<DanaG> ah.
<DanaG> heh, I'm on Pacific time.  Just about 11 PM here.
<DanaG> Anyway, I lost track of the wiki thing with the initramfs setup script... do you remember where that was?
<rcn-ee> ah cool, 1am here, going to give .1-dl5 a test, as i see it's done..  the initramfs stuff is on the talk/discussion page, haven't moved it to the main wiki as it's not finalized... ;)
<DanaG> ah.
<DanaG> I've had bad luck with suspend/resume... only once have I ever gotten it to even suspend.
<DanaG> And sometimes the gpio-keys thing works... other times it doesn't.
<rcn-ee> i'm suprised your having problems with asix..  all the other hardware adapters have failed me over the last 2 years. ;)
<DanaG> Oddly enough, unplugging it for a minute or so, and then plugging it back in, seemed to fix it.
<DanaG> I'
<rcn-ee> weird, i can't do that on my machines, they are in the racks..  i can switch power on/off...
<DanaG> I'm also using the new u-boot announced on the mailing-list, with support for expansion boards... though I don't have any such boards.
<rcn-ee> It looks interesting, my zippy2 is on my desk at work so i can't test it till monday...
<rcn-ee> sweet .1-dl5 works...
<Baybal> hi
<Baybal> qsd8762 is a true monster
<rcn-ee> talk about a weird bug triggered by the .config with gcc 4.4...
<Baybal> where I can order a dev board?
<rcn-ee> which one?
<Baybal> any
<Baybal> preferably with hdmi
<Baybal> preferably official
<rcn-ee> does in-progress count as official? ;)  I'm a little bias towards the omap/beagle's since i've been working with them for a number of years.. ;)
<DanaG> what's the ETA on the XM?  That's the most well-known and well-available thing I've seen.
<DanaG> hmm, still wondering why I always get "class suspend failed for cpu0"
<rcn-ee> Last Jason/Gerald where saying was mid/early summer..  The proto's are out and being tested, but finaly memory size hasn't been completely decided..
<DanaG> the asix does support WOL in Windows on my host; haven't tried it in Linux on my host.
<DanaG> But ethtool offers "supports WOL: pg"
<Baybal> ok if no other variants
<DanaG> oh, and now I see that lack of NAND on beagle-XM won't be such a big deal for me... I'd have root on SD, anyway.
<Baybal> I wonder how all this super puper soc manufacturers are supposing to make their products successful while nobody ever seen them outside of a website?
<rcn-ee> Baybal, Crap, out of stock, should have more in this week: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=296-23428-ND
<DanaG> http://www.hwtools.net/ExtenderBoard/TFEX.html
<DanaG> interesting.
<DanaG> anyway, dl5 boots fine without initrd; just doesn't suspend.
<rcn-ee> the lack of Nand gives more room in memory space for ram..  It's just a question if micron can make it. ;)
<DanaG> None of the kernels have suspended reliably for me... though perhaps changing u-boot versions affects that.
<DanaG> hmm, on beagle XM, which way does the SD slot point?
<DanaG> It'd be nice if it pointed in a way that made this thingy not dangle off the side. =P
<rcn-ee> now that we got the boot problem fix, i'll play around tomorrow with suspend stuff, it's related to the power management stuff..
<DanaG> oh, and how do you tell Linux to keep the video-output stuff just plain OFF?
<DanaG> I don't need it for now; might as well save a bit of power and RAM.
<Baybal> there are only omap based,  I want qsd 8762 based
<rcn-ee> it's actually a  micro sd card slot now, so it'll stick out less then otg plug. (it's also under the board)
<rcn-ee> ahh sorry, didn't know gsd 8762 was actually an arm variant...
<DanaG> hmm, anyway, check out that adapter.  Lets you stick full-size SD into micro-sd slot.
<rcn-ee> Part of enabling DSS2 also allows us to control the power regulators, so you can turn off video sections..
<DanaG> It just dangles away a bit.
<DanaG> hmm, neither qsd nor gsd 8762 give me any results in google.
<DanaG> rather, no meaningful results.
<DanaG> oh, snapdragon?
<rcn-ee> i think it's qualcom?
<DanaG> hmm, qualcomm 8762 also gives nothing useful.
<Baybal> snapdragon2
<Baybal> 8672
<Baybal> sorry
<Baybal> QSD8672
<rcn-ee> qualcomm is always fun, i think your going to have to inquire them directly for a development kit...
<Baybal> ...
<Baybal> yaa
<Baybal> It's first soc featuring new gen. ati imageon and such a disgrace
<Baybal> twice as powerful as top configurations of sgx540 and mali400
<DanaG> is imageon supposed to be anything like radeon?
<Baybal> think of it as ati 8500 in a bga
<Baybal> yes, desktop comparable performance
<DanaG> ah. cool.
<DanaG> anyway, enough messing with beagleboard suspend for one night/day/night/whatever.
<Baybal> now we have some sammy hw and supposed to do a phone design
<rcn-ee> last i read it's lossely based on what went into the r500 family, so it might have the best 3d support of any arm chip..
<DanaG> My sole criteria for "useful 3D" on any platform: Can it run Compiz?
<DanaG> Even my old Radeon 7500 can.
<Baybal> the worst part is that q has not even put a normal datasheet on power consumption
<Baybal> imageon thing would be fine if it would drink less than a half of total chip tdp
<rcn-ee> what i hate about the sgx...  well you have to run this specific binary for any 3d stuff and it's not that good..
<DanaG> what does glxinfo on it show?
<DanaG> my sd card is not big enough to fit the sdk... will have to get bigger SD card before I can try.
 * Baybal looking toward ST8500
<Baybal> I just wonder where all those A9 based dev boards goes
<rcn-ee> i should actually run glxinfo and see.. i usually load the modules with the binary's and just verify the demo's work...  it's like 300-400Mb over your rootfs, 4GB's card work for that..
<rcn-ee> they are in high demand...  The tegra is about the easiest dual a9 to get at this point..
 * Baybal already has 2
<rcn-ee> how do you like it?  I've heard good things from martin
<Baybal> glx working 1 minute then goes blackscreen
<Baybal> looked for mesa bugs, xorg... find a bug in kernel
<Baybal> performance comparable to sgx 535 thing
<Baybal> I actually awaited more...
<rcn-ee> laughs... sounds like they need more boards out their for people to debug/test for them..
<DanaG> hmm, what 3D chip is tegra?  I know NV... but what NV desktop chip is it light?
<DanaG> er, like.
<Baybal> I'm not a person who is developing design for tegras, probably would as them
<rcn-ee> wikipedia calls it a geforce ulv
 * DanaG goes off to bed.
<DanaG> it's a bummer there's no open ATI+ARM.
 * Baybal wonders of android guys working on 4+ separate trees and complaining nobody doing backporting for them
<rcn-ee> ARM with a pci express bus, then i'll add ati graphics.. okay 2am, later..
<DanaG> good night. =P
<Sayag_Samuel> hi,
<Sayag_Samuel> I have installed Ubuntu Karmic on the Beagle c4, and now I'm checking the image with putty. Does it suppose to hold that long on the "Free  init memory 188K" ?
<Sayag_Samuel> It's about 5 min now ...
<Sayag_Samuel> Okay it looks like it stuck
#ubuntu-arm 2011-03-21
<bkero> persia: ping
<hrw> morning
<dmart>  
<ogra> grr
<lil_pete> hey guys does anybody have problems with usb-hotplugging at a toshiba tegra-platform? maybe even a solution to problems relatet to that? :)
<ogra> works fine on my ac100
<lil_pete> well i got a folio100, pretty much the same system, but only one usb port
<lil_pete> could you pastebin your dmesg and gzip -dc /proc/config.gz please?
<ogra> http://ac100.gudinna.com/kernel/ has the config
<ogra> note that the folio and ac100 kernels are massively different (they arent cross functional) so you can just blindly apply this config to a folio kernel
<lil_pete> ooohhh... dyou know about any details?
<lil_pete> 'coz i thought since usb should be somewhere on the tegra-chip it _should_ be the same config in both kernels?
<ogra> nope, ask in #ac100, i think phh did some tests
<lil_pete> didnt know that toshiba patched that much
<ogra> oh, related to usb they might be the same
<lil_pete> well i _thought_ so, but thats just blind assumptions, i never touched an ac100
<ogra> but that doesnt make the folio kernel bootable on an ac100 ;)
<lil_pete> ill ask in ac100
<lil_pete> well if i wanted to i couldnt, i have a custom kernel since i need some wicked custom drivers, but as i said... i thought that usb-stuff should run out of the box
<ogra> it does as long as your kernel properly provides everything udev expects
<lil_pete> im wondering if its some energy saving issue or something i messed up in the config... dunno.
<lil_pete> hehe thats the funny thing, if @ boot i plug in a usb-hub, i can plug/unplug everything i want to that hub. if i unplug the hub, its like usb is dead, nothing in dmesg at all. its... weird. :)
<ppisati> guys, in maverick to support a beagle board/xm, which kernel branch did you use? master? linaro? ti-omap? or ti-omap4?
<ppisati> during boot, my Xm says:
<ppisati> [    0.000000] Linux version 2.6.35-22-omap (buildd@gourd) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu Mon Sep 20 03:17:30 UTC 2010 (Ubuntu 2.6.35-22.33-omap 2.6.35.4)
<ppisati> so i guess it's linaro, right?
<lool> ppisati: This only says which compiler was used
<lool> ppisati: In this case, one with the Linaro patchset applied
<ogra> ppisati, for omap3 we use mainline
<ogra> omap4 is a special breed from mainline, TI patches and linaro patches
<Xase> I'm interested in learning me some ARM and running Ubuntu on "a device similar to a beagle board?"
<Xase> http://elinux.org/BeagleBoardUbuntu#Demo_Image << I'm assuming trying this, and reading here will lead me in the right direction oh armites?
<GrueMaster> Do you already have a beagleboard?
<Xase_> GrueMaster: sorry my daughter pressed the sleep button.
<GrueMaster> Heh.
<Xase_> No, I don't however the Nook Color is really similar in processor and graphics processor.
<Xase_> I was wondering if the demo image would boot over SD or at least throw a kernel panic.
<GrueMaster> Similar in that it is arm based.  That's about it.
<Xase_> ... eh.
<GrueMaster> Slightly different processor than what is on the beagleboard.  In the arm world, the kernel needs to almost be specific to the system.
<Xase_> Well... so it'll at least throw a kernel panic?
<GrueMaster> We have people working to unify the code so we have one kernel, but it will take some time.
<Xase_> Well I was thinking of rebuilding the Cyangoenmod kernel from android with the extra requirements for running a GNU/Linux distro
<Xase_> So I technically have a kernel already =/
<GrueMaster> I'm not sure what it would do.
<Xase_> Well it would obviously needs to be configured to use the right display and all that nonsense.
<GrueMaster> You should google to see if someone has already hacked the nook.
<Xase_> Glad to finally hear some info form here.
<GrueMaster> There is more to it than just the kernel.
<Xase_> Well by hacked do you mean rooted?
<Xase_> I have a custom kernel on mine running already =/
<GrueMaster> Yes, and has a link to a working base image.
<Xase_> But it's still android... I wanted to step beyond that.
<Xase_> Do you think my idea is plausible however? at least trying to get it to work?
<Xase_> Like if I stuck at it, I could get it working near 100% capacity?
<GrueMaster> Personally, I only get to work on specific hardware that is officially supported by the current release.  That limits me to beagleboard, beagleXM (same kernel for both now), and Panda (dual core).
<Xase_> Ah.
<Xase_> What processor is in the beaglebord?
<GrueMaster> It is very plausable to get it working.  Others have done similar work with the Viewsonic tablet and the Toshiba AC100 smartbook.
<GrueMaster> The beagleboard & XM are omap3, just slightly different configurations than the nook.
<GrueMaster> So the omap kernel from Ubuntu may work wit hsome slight tweaking (or it might just work).  I don't know.
<rsalveti> probably need the correct board file
<rsalveti> with proper platform devices and drivers
<Xase_> Hmm, I think I'll have a look at it and a talk with some associates who think I'm crazy.
<rsalveti> so I'd say that you probably need some additional patches to make it fully compatible with nook
<Xase_> I am all new to this
<GrueMaster> http://forum.xda-developers.com/showthread.php?p=10306407
<rsalveti> Xase_: what is your kernel version?
<Xase_> That is nonsense though, it's just running basically as a VM rsalveti
<Xase_> hold on I'll check
<Xase_> 2.6.32.28
<rsalveti> urgh
<rsalveti> old
<Xase_> Yeah.
<Xase_> I don't expect it to be easy, and I know it will take awhile, I was just curious as to how plausible it is.
<GrueMaster> Check the link I posted above.  It has a howto for Ubuntu.
<Xase_> ... yeah to run it inside of android though =/
<Xase_> Does that hold any relevance to my ideals in the long run.
<Xase_> .sa0z56'tgh 6\tb ]6\5
<Xase_> Sorry
<rsalveti> it's probably plausible
<Xase_> My daughter is amazingly computer loving.
<rsalveti> would be good to check what bootloader are you using
<rsalveti> if it's possible to load an initrd file
<rsalveti> then see if it's possible to port the specific patches to at least 2.6.35
<rsalveti> so you can safely use the maverick rootfs
<rsalveti> or 2.6.38 if you want to use natty
<Xase_> Alright, I'll do some more reading then :D
<Xase_> It uses uboot on nand
<rsalveti> cool
<Xase_> Well I'll be back, and I'll read some on the kernel while I'm out.
<rsalveti> alright
 * rsalveti bbl
#ubuntu-arm 2011-03-22
<slnr> hi
<slnr> I have a query with fakesink
<slnr> did anyone try this
<slnr> gst-launch filesrc location= xyz.mp4 ! qtdemux ! nal2bytestream_h264 ! omxh264dec ! fakesink
<slnr> seems have problem
<ogra> WOHOOO !!!!
<ogra> serial output of oam-config on the serial console
<ogra> finally !!!
<ogra> *oem
<GrueMaster> ogra: Great!.  What was it?
<ogra> GrueMaster, debian-installer/framebuffer defaults to true
<GrueMaster> ah.
<ogra> setting it to false forces serial
<ogra> now tracking the missing user creation
<ogra> and why serial is so screwed up wrt display
<ogra> GrueMaster, do you usually use screen or minicom for serial ?
 * ogra would like to know if the UI looks any better under screen
<GrueMaster> I use minicom due to its logging capabilities, but have used screen also.
<GrueMaster> (and it is more familiar to me).
<ogra> i would like to know if the window frames are as screwed up as in minicom ... i cant really see whats selected ofr example
<ogra> *for
<ogra> and the frames are all special chars
<ogra> also UTF-8 seems to not work at all
<GrueMaster> I'll look into it.  Is the fix for oem-config on today's image?
<GrueMaster> Or can I munge it to work?
<ogra> you can just use the last build from today
<ogra> (i did several the last two days)
<ogra> just dont expect it to create a user :)
<ogra> seems the final bit of ubiquity isnt run at all (its not in the debconf UI code in ubiquity)
<ogra> so thats why we end up without user
<GrueMaster> ah
 * ogra fires up another isntall to collect some screenshots
<ogra> GrueMaster, exporting TERM=vt100 before minicom makes the UI work
<GrueMaster> ok
<GrueMaster> That can also be set in minicom.
<ogra> likely
<ogra> but i would like to see it working on the other side actually :)
<ogra> so we dont need to change it on the client side
<GrueMaster> wait, what?  The TERM=VT100 should be set on the host (minicom) side, right?
<GrueMaster> What does that have to do with the image?
<ogra> i want debconf to provide the right stuff that we dont have to switch from xterm to vt100
<lool> Is this over serial?
<ogra> lool, yep
<ogra> oem-config
<lool> The thing is this is going to depend from your connecting terminal, if you connect from linux console instead it will be different; you could use SSH instead as to pass the terminal information
<ogra> lool, bug 736111
<ubot2> Launchpad bug 736111 in ubiquity "oem-config does not respect the console on serial tty" [High,New] https://launchpad.net/bugs/736111
<ogra> lool, well, it would be good if a default gnome-terminal connection gets me a working UI
<ogra> sure i might connect somehow different but i want a working default
<ogra> i think in console we export linux for TERM
<lool> Why would the default be gnome-terminal?
<ogra> so i would like to see it working with xetrm and linux set
<ogra> well, gnome-terminal, xterm kterm whatever
<ogra> they should all use the same TERM setting in ubuntu afaik
<lool> It's all different emulations
<lool> Anyway, I'm sure cjwatson can provide better input
<lool> but you could consider SSH as well, this would avoid the problem entirely
<ogra> not for natty
<ogra> extending the headless image to different other install variants isnt something i want to do right before beta
<mikc> Hi, does anyone know how to play a full HD movie on the pandaboard ? I installed the omap4 addons, and it does not seem to work.
<amelim> I just booted the OMAP3 image on my gumstix overo as per these instructions here https://wiki.ubuntu.com/ARM/OMAPMaverickInstall and it took me immediately to the ubuntu login screen. I replaced the fat32 partition with pre-built MLO, u-boot, and uImage from Gumstix Is there some sort of default credentials I should be using? I was under the impression it would do an install process
<rsalveti> amelim: you're probably not loading the uInitrd, then the installer will not start
<rsalveti> as a consequence no user is created
<amelim> can I grab that file separately somewhere or will I have copy the whole preinstalled image over again?
<rsalveti> amelim: it'd be good to copy it from the preinstalled image, as it's the first initrd created, with instructions to startup the installer and do the disk resize
<rsalveti> amelim: but you can also mount the img file if you have that at your host, and just grab the file without the need to write it again
<amelim> I'm just reflashing my SD to get a fresh image. Should I encounter any issues if I just copy over the gumstix specific files directly to that partition?
<rsalveti> amelim: it should work, if your u-boot is loading the boot.src file
#ubuntu-arm 2011-03-23
<Amaranth> are the daily images for omap4 working?
<ogra_> should, yes
 * ogra_ hasnt tested any graphical ones recently, only headless 
<Amaranth> ogra_: ah, that's the part I'm worried about, linaro images apparently don't turn on the display
<ogra_> the ubuntu ubuntu-netbook ones do
<ogra_> just use these
<Amaranth> Yeah, I'm getting the one from http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/current/ now
<ogra_> that should be fine, if you have probs with it, the alpha-3 one definitely works and was tested
<ogra_> (see topic for url)
<davidgiluk> for those interested, there is a an ARM porting Jam on #linaro this time every week; it's not too busy but if anyone knows of particularly pesky ARM only bugs or if anyone needs help with ARM tools/porting, please come and ask
<ogra_> davidgiluk, yes, we all get the gcal notifications ;)
<davidgiluk> ogra_: I assumed those in this channel weren't all on these lists
<ogra_> davidgiluk, but nobody will fix bug 739374 for me anyway :P
<ubot2> Launchpad bug 739374 in eglibc "eglibc newer than 2.12.1 in natty results in alignment errors, SIGLILL and segfaults on tegra2 systems" [Undecided,New] https://launchpad.net/bugs/739374
 * davidgiluk looks
<davidgiluk> ogra_: Youch, that's a nasty errata
<ogra_> yes
<ogra_> and no real fix for libc
<ogra_> that indeed wont help to get nvidia on board with linaro ever
<ogra_> (or with ubuntu)
<davidgiluk> ogra_: Is the details of that errata public?
<ogra_> well, the kernel code as well as bionic are public ... not sure what else you need
<ogra_> i doubt nvidia released anything with more details
<davidgiluk> ogra_: So what's the problem exactly - bit 20 always reads in one way or do you get junk out?
<ogra_> i cant boot :)
<ogra_> nor can i chroot
<ogra_> so its a bit hard to debug at all
<ogra_> chrooting immediately segfaults, booting dies very early with alignment errors and SIGILLs
<ogra_> currently i use the natty libc pinned in apt to have a working system at all
<ogra_> and i have no idea how to debug such early userspace issues
<davidgiluk> ogra_: I'd probably start with a statically build busybox
<ogra_> right, if i hadnt beta freeze tomorrow i would invest that time :)
 * ogra_ uses his tegra as main work machine so its a bit hard to tinker with it 
<ogra_> given the feedback from peter it seems like a pretty desparate issue anyway
<davidgiluk> ogra_: I mailed Gary King of Nvidia who did that patch to ask if he can give any more detail on the failure mode
<ogra_> sweet ! why didnt i think of that !
<davidgiluk> did you?
<ogra_> no i didnt :)
 * davidgiluk admits to knowing very little about TLS, but it strikes me if the failure is anything other than returning random junk then it might be possible to align the allocation - still painful, but it might actually work
<ogra_> well, you actually need to know you are on a tegra etc
<ogra_> that will likely be hard to do inside libc
<davidgiluk> ogra_: Nah
<davidgiluk> ogra_: Messy, not hard
<ogra_> well, messy yeah
<ogra_> :()
<ogra_> bionic just bends the headers at build time
<davidgiluk> ogra: I'm fairly sure I saw something about some other hardware having specific TLS memory, so perhaps it's not too unusual
<ogra_> hmm
<davidgiluk> <sigh>
<davidgiluk> ogra_: Well, the bad news is that his email address bounces
<ogra_> bah
<davidgiluk> ogra_: I've mailed a random other Nvidia person I found in a commit log :-)
<ogra_> heh
 * ogra_ crosses fingers 
<ogra_> ... and goes back to bang his head against bug 736111
<ubot2> Launchpad bug 736111 in ubiquity "oem-config does not respect the console on serial tty" [High,New] https://launchpad.net/bugs/736111
<amelim> Are there any rootfs tars of Maverick available other than the pre-install image? I tried building one with rootstock, but I'm continually running into issues of it hanging during the process.
<lool> amelim: a) use a recent qemu-linaro, if you're not running natty, you can use the ~linaro-maintainers/tools PPA and install qemu-user-static from there b) there are alternatives solutions to rootstock I can hint at if it doesn't help
<Amaranth> Is the preinstalled image supposed to turn on the screen before the first-run unpacking is complete or does it wait until after?
<Amaranth> wondering if I should give this time or dig out my serial adapter
<ogra_> natty ?
<Amaranth> yeah
<ogra_> do you use DVI ?
<Amaranth> no, HDMI plugged in to the first port
<ogra_> the current image doesnt support HDMI, only DVI with fixed 720p
<Amaranth> *headdesk*
<ogra_> new kernel with a fix that works like in maverick was just uploaded today
<ogra_> should be in by the weekend
<ogra_> until then you need to use DVI
<prpplague> i guess i need to check and see if they got the regulator patch included
<Amaranth> I wouldn't have the proper adapter until the weekend anyway
<Amaranth> I don't even own a DVI cable :P
<GrueMaster> Amaranth: The "DVI" port uses the same signalling as the HDMI port (except audio).
<GrueMaster> So the same cable should just work.
<Amaranth> GrueMaster: So I can plug an HDMI cable in to it and it'll show something, just locked to 720p?
<prpplague> Amaranth: http://pandaboard.org/content/resources/references
<GrueMaster> yes.
<GrueMaster> That's how I test here.
<prpplague> Amaranth: there is a table there describing the different combinations
<Amaranth> ok, I guess it needs a reset to know to probe for it, hope it was done with the first boot extracting :P
<Amaranth> ooh I have an offset plymouth
<amelim> lool: I'm on a lucid distro, if I install qemu-user-static will I need to remove any other qemu packages for rootstock to run correctly?
<lool> amelim: We renamed various packages around since lucid; what you'll be getting is an equivalent set of features, but provided by different package names
<lool> amelim: You might have to upgrade other packages as well, but essentially it's different package names with same contents but newer versions
<lool> and eventually, when you upgrade to some later Ubuntu versions, you'll have the same package names provided by Ubuntu
<lool> (these are just backports)
<Amaranth> hmm, it seems to have rebooted and now plymouth is showing correctly, this seems promising
<amelim> ahhhh, ok
<Amaranth> yay it booted, thanks GrueMaster
<GrueMaster> np.
<ogra_> now fix compiz !
<ogra_> :)
<GrueMaster> Are you trying the netbook image or the headless image?
<Amaranth> GrueMaster: netbook
<Amaranth> ogra_: Well, I have this code that compiles and I'm pretty sure does the right things but GLES is apparently broken in mesa for sandy bridge so I haven't been able to run it
<Amaranth> Thus getting real hardware going
<GrueMaster> There is a bug in jasper that breaks video output after first boot.
<ogra_> GrueMaster, hmm, how so
<ogra_> i dropped all special casing for video stuff recently
<ogra_> it hands through the cmdline directly now
<GrueMaster> ogra_: Your fix hasn't landed in an image yet.
<ogra_> hmm, it should be in headless
<GrueMaster> As the current image is 20110321.
<GrueMaster> Not in netbook
<ogra_> no, indeed
<ogra_> blame kdelibs
<Amaranth> crap
<Amaranth> Oh, I blame KDE for everything, don't worry
<ogra_> heh
<ogra_> and glib too
<ogra_> first glib was out of sync, now kdelibs held up a lot of subsequent stuff (like compiz)
<GrueMaster> How do you add icons to either the launcher or places in unity-2d?
<ogra_> we should drop these crappy graphical images and just resort to headless everywhere :P
<GrueMaster> And how does kdelibs hold up compiz?
<ogra_> heh, compiz build depends on them
<ogra_> no idea why
<Amaranth> compiz pulls in _everything_
<GrueMaster> Very odd.
<Amaranth> kdecompat plugin (plasma stuff), kde4-window-decorator, and the kconfig compizconfig backend
<GrueMaster> And people say they don't work with other environments...sheesh.  :P
<Amaranth> If you need to make sure you have -dev packages for every possible GUI app you ever want to build just apt-get build-dep compiz
<GrueMaster> So, back to my unity-2d question...
<ogra_> no idea
<ogra_> places should be connected to nautilus places
<ogra_> somehow
<GrueMaster> and that gets updated...how?
<ogra_> so adding one in nautiluxs might show up in the launcher
<GrueMaster> Isn't nautalis used in the une-efl?
<Amaranth> hmm, this doesn't look like 720p
<Amaranth> looks more like 640x480
<GrueMaster> Amaranth: Yea, that's the jasper bug.
<GrueMaster> You can fix it by editing the /boot/boot.script.
<Amaranth> Don't I have to extract that from boot.scr then regenerate it?
<GrueMaster> add "omapfb.mode=dvi:1280x1024MR-32@60 omapdss.def_disp=dvi" to the bootargs, then you need to rerun mkimage on the file.
<GrueMaster> The /boot/boot.script is a text version of the u-boot script.
<Amaranth> might as well enable the serial console while I'm in there, in case I screw it up :)
<GrueMaster> It is in the root partition.  After editing it, rerun "mkimage -A arm -O linux -T script -d mnt/boot/boot.script boot.scr".  Then umount the second partition, and copy the boot.scr to the fitst partition.
<ogra_> huh ?
<ogra_> sudo flash-kernel
<GrueMaster> Kind of a pita, but the next image should fix this.
<ogra_> no need to run any mkimage
<GrueMaster> ogra_: That is assuming you are already running.  oem-config has major issues on 640x480.
<ogra_> (on the running system)
<Amaranth> I am running
<ogra_> ah, k
<Amaranth> oem-config has zero issues if you know alt-button1 moves the window around :)
<GrueMaster> My steps can be done on the desktop system.
 * ogra_ didnt know oem-config misbehaves
<GrueMaster> oem-config windows are designed for *x600 screen height.
<ogra_> Amaranth, well, just edit /boot/boot.script and run sudo flash-kernel afterwards then
<ogra_> on next reboot the new config will be used
<Amaranth> hrm, says something is using /dev/mmcblk0p1 so it can't unmount it
<Amaranth> but as far as I can tell the mount point is one flash-kernel is creating
<Amaranth> But it seems to be writing things properly, just not completing umount afterward so I guess it's reboot time
<Amaranth> dang, mode not supported, guess it's a good thing I put that serialtty bit in there
<ogra_> well, you can always use GrueMaster's method above with your desktop PC
<Amaranth> that's no fun :)
<GrueMaster> No one ever said my job was fun.  :P
<Amaranth> so with the next kernel update none of this will be needed, right?
<ogra_> yes
<ogra_> will behave exactly like in maverick
<GrueMaster> Ok, figured out how to hack in the ti addons icon into unity-2d.  The method is anything but user friendly.  :(
<GrueMaster> But it looks good.
<ogra_> oh, for favorites ?
<ogra_> thats trivial, there is a gconf key
<GrueMaster> That's what I was asking about.
<GrueMaster> Thanks.
<ogra_> no, you asked about adding an icon to the launcher
<ogra_> or to places
<ogra_> nothing indicated you wanted a new favorite
<GrueMaster> And the launcher currently has it's own list of favorites.
<ogra_> jasper should take care post beta
<ogra_> yeah
<ogra_> same goes for hiding behavior
<GrueMaster> sigh.
<ogra_> and the method doesnt need to be user friendly, no user should use it ;)
<GrueMaster> No user would ever want to add their own favorite app to the favorites?
<GrueMaster> You're kidding, right?
<ogra_> not programmatically
<ogra_> drag and drop is implemented in the latest upload afaik
<GrueMaster> Nope.  I'm running unity-2d daily.
<GrueMaster> For Maverick.
<ogra_> users will never have to fiddle with the gconf system default
<ogra_> maverick ...
<GrueMaster> Well, until D&D works...
<ogra_> it makes use of unity features for that afaik
<ogra_> so needs natty
<GrueMaster> The unity-2d is from the ppa.
<ogra_> but not the unity :)
<ogra_> it uses the dash backend afaik
<lool> ogra_: I thikn you can close multiple bugs with LP: #123, #456
<ogra_> lool, but that wouldnt give me the ascii art :)
<lool> it would give you a different one
<ogra_> yeah
<ogra_> i'll use it next time or teach upstream about using dch
#ubuntu-arm 2011-03-24
<Amaranth> crap, got a kernel oops during apt-get upgrade and it made my filesystem go read-only
<Amaranth> This is going to suck to recover
<rcn-ee_> Amaranth, any chance do you still have the oops?
<Amaranth> rcn-ee: I don't, completely forgot to save it before I tried to reboot
<Amaranth> whoa, it's really broken
<Amaranth> fsck fails, says to run it manually, then everything else fails because the filesystem is still readonly
<rcn-ee_> ouch, where you running anything special for a kernel?
<Amaranth> nope, just installed the latest netbook image
<Amaranth> wow I think it's more corrupt than not, fsck is just streaming "Inode 132 was part of the orphaned inode list."
<Amaranth> wow, and now I got this mess http://pastie.org/pastes/1706348/text
<Amaranth> Think it's time to reimage
<rcn-ee_> ouch, haven't seen that one before..
<Amaranth> It's weird because that partition wasn't touched
<Amaranth> And I don't think I've made it out of the initramfs at that point
<Daexpos> Jelou
<rsalveti> Amaranth: you can find the new kernel at https://launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.38-1206.7/+buildjob/2339351
<rsalveti> Amaranth: and then you can install the sgx drivers from tiomap-dev/trunk ppa
<rsalveti> just install the linux-header packages and the linux-image one
<Amaranth> d'oh, I just started setting up a linaro image :)
<ogra_> the curse of the impatient ones ;)
<rsalveti> well, it's not going to work better for you ;-)
<ogra_> bug #318727
<ubot2> Launchpad bug 318727 in dkms "dkms wrong version of linux-headers" [Unknown,Fix released] https://launchpad.net/bugs/318727
<Amaranth> oh man, the omap4 kernel FTBFS
<rsalveti> Amaranth: grab https://launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.38-1206.7/+buildjob/2339351
<rsalveti> urgh, abi changed
#ubuntu-arm 2011-03-25
<uragano2> Hello!
<prpplague> greetings earthling
<uragano2> Hello! how can i solve this problem? install: cannot stat `xbmc.bin': No such file or directory
<uragano2> make: *** [install-binaries] Error 1
<uragano2> i downloaded th source code and runned bootstrap, configure and make without error (i haven't seen it maybe ) on my pandaboard, but when i send make install it returns this error
<Amaranth> well it ended up taking me two days but I now have up-to-date natty with gles acceleration on my panda
<Amaranth> apt-get build-dep compiz will probably be an overnight job though
<rsalveti> cooloney: don't know if you noticed, but the kernel build failed because of abi changes
<rsalveti> Amaranth: getting an usb disk based rootfs helps a lot
<rsalveti> dpkg is quite io intensive
<cooloney> rsalveti: really? i built it locally successfully
<Amaranth> rsalveti: Isn't usb IO still like 6MB/s?
<cooloney> rsalveti: which version? 1206.8?
<rsalveti> Amaranth: nops, a lot faster than usual sd cards
<rsalveti> cooloney: yup
<rsalveti> cooloney: tim just updated it
<rsalveti> still not built, update was 22 min ago
<Amaranth> rsalveti: the linaro wiki page links to a bug report that shows it's horribly slow
<Amaranth> But it's probably still faster than the SD card which is also apparently horribly slow
<rsalveti> Amaranth: well, I got two pandas with usb disk, and for sure it's a lot faster
<rsalveti> to build and use
<rsalveti> probably not full speed, but for sure faster than sd :-)
<Amaranth> Yeah, I've noticed most of my issues are IO wait
<Amaranth> I guess it's time to get a usb hub and external HD
<cooloney> rsalveti: i'm also working on the HDMI audio updates from andygreen.
<cooloney> rsalveti: will try to fix this thing and send out update
<rsalveti> cooloney: what kind of updates, fixes?
<cooloney> rsalveti: patches for HDMI audio, andy got them from TI guys
<rsalveti> oh, ok
<uragano2> Amaranth: did u have any problem when you up-to.date natty?
<Amaranth> uragano2: had to pull a kernel directly from launchpad to get hdmi to light up
<Amaranth> and I have a weird system, it created my image with a linaro hwpack and rootfs then pulled in an ubuntu kernel and other stuff
<uragano2> i have just installed natty, but screen is black :S
<rsalveti> uragano2: are you using the dvi output?
<uragano2> nope, hdmi
<rsalveti> hdmi is only supported with the kernel that was just uploaded
<rsalveti> latest daily image just supports dvi
<Amaranth> rsalveti: that's not quite true though, I was able to plug an HDMI cable in to it
<uragano2> hmmm...my tv doesn't support dvi
<Amaranth> But you need to plug in to port 2, don't use any adapters (other than HDMI->DVI if needed) and you get 640x480 if you don't edit your boot.script
<Amaranth> uragano2: but ubiquity doesn't fit on 640x480 so you'll need to use alt-button1 (left mouse) to drag the window around to finish the setup
 * uragano2 is going to try
<Amaranth> hmm, I think I should just get a USB flash stick for the panda instead of a hard drive
<rsalveti> Amaranth: yeah, I mean the dvi output from panda
<Amaranth> rsalveti: that's confusing though because it's actually an hdmi port :)
<uragano2> ok, i linked my tv to hdmi port (the nearest to eth)
<uragano2> is this right?
<uragano2> my screen is still black
 * uragano2 is coming back to ubuntu 10.10
<rsalveti> uragano2: you should use the other hdmi port
<rsalveti> the nearest to eth is the hdmi
<rsalveti> the other is dvi-d
<rsalveti> and it's the only one currently supported by natty's daily image
<uragano2> i tryed to use, but screen is black
<rsalveti> you could get the newer kernel and install at your rootfs, to have hdmi support
<rsalveti> but for that you'll need to mount at your host and use qemu to install the newer kernel
<uragano2> i am a beginner in linux. i am reading about qemu
<uragano2> hmmm...exists standard options for pandaboard? :D
 * uragano2 decided to wait for a working release!
<uragano2> goodnight
<hrw> does someone uses 460+512 memory setup on panda?
<ndec> hrw: there is a known issue with this config related to HIGHMEM
<ndec> ogra_: hi. i just an email. no weekly call today, sorry... ;-)
<ogra_> ndec, fine with me
<rbelem> rsalveti, pign
<rbelem> *ping
<mikc> Hi, I have trouble with Ubuntu on the pandaboard - It's slow, crashes often, does not play HD files, sometimes sound does not work, and screen resolution is incorrectly detected (640x480 on a Full HD monitor)
<mikc> I follow the procedure on omappedia.org - Is it up to date? I did it 4 times, with the same result each time...
<rsalveti> mikc: with maverick?
<rsalveti> mikc: are you using the tiomap-dev/trunk ppa?
<mikc> rsalveti: I follow the procedure to the letter
<rsalveti> mikc: http://omappedia.org/wiki/Ubuntu_OMAP_trunk
<rsalveti> mikc: try updating your packages with this ppa
<mikc> Thanks, I'll try that
<mikc> http://www.omappedia.org/wiki/PandaBoard_Ubuntu_PPA I used thsi one
<rsalveti> should have new kernel and updated packages for gst and sgx
<mikc> rsalveti: ok, sry I'm in a SC2 game right now
<rsalveti> at least I'm using this ppa and I'm able to play fullhd videos just fine
<rsalveti> mikc: np
<mikc> rsalveti: cool!
<mikc> Will try that
<mikc> rsalveti: Thanks for the pointers
<rbelem> rsalveti, ping
<rbelem> Hi all, do you know if usb otg work on natty?
<rsalveti> rbelem: hey, sorry, just saw that you also pinged me
<rsalveti> rbelem: omap 3 or omap 4?
<rsalveti> that depends on the kernel used
<rbelem> rsalveti, np
<rbelem> :-)
<rbelem> rsalveti, omap3
<rsalveti> rbelem: need to check, last time I remember it still needed one additional patch that cooloney sent upstream but wasn't applied
<rbelem> rsalveti, i got the image from here http://cdimage.ubuntu.com/kubuntu-mobile/daily-preinstalled/current/
<rsalveti> rbelem: will check later today if beagle is working with it
<rsalveti> still need to download latest image, or update it
<rbelem> rsalveti, it is working here, but i could not plug keyboard, mouse, etc...
<rsalveti> rbelem: are you using it with a powered hub?
<rsalveti> and proper cable?
<rbelem> rsalveti, yup
<rsalveti> so could be a bug
<rsalveti> it's probably the same bug we had with maverick
<rbelem> rsalveti, i turned a mini b into mini a :-)
<rsalveti> got it :-)
<rbelem> rsalveti, i subscribed myself in that bug
<rsalveti> rbelem: do you have the bug number?
<rbelem> yup
<rbelem> rsalveti, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/608312
<ubot2> Launchpad bug 608312 in linux "Usb host mode on OTG doesn't work on Maverick with BeagleBoard" [High,In progress]
<rsalveti> cool, thanks
<rbelem> rsalveti, do you know if usb otg works in the pandaboard?
<rbelem> http://omappedia.org/wiki/Ubuntu_on_OMAP_FAQ#USB_OTG_port_on_PandaBoard_does_not_as_host_under_Ubuntu
<rsalveti> rbelem: not with current kernel
<rsalveti> but should be fixed soon
<rbelem> cool :-)
<rbelem> rsalveti, do you have any spare pandaboard that you could sell? :-)
<rsalveti> rbelem: unfortunately no
<rbelem> :-(
<rsalveti> I have 3 pandas, but all from canonical
<rbelem> rsalveti, do you know if the digikey send to here?
<rsalveti> rbelem: don't remember, but should be able to send it just fine
<rbelem> rsalveti, cool! but the major problem would be the taxes
<rsalveti> yeah :-(
<rsalveti> 60%
<rbelem> omg
<rbelem> plus 17% of icms
#ubuntu-arm 2012-03-19
<mark920> Does anybody know how to get DVI-D enable using the bootargs omapdss.def_disp=dvi and omapfb.mode=dvi:1024x600MR-24@60 ?
<mark920> I dont know how to add these bootargs to the kernel properly
<mark920> I tried adding them to the boot.script and through U-boot.
<mark920> admin
<olegfink1> mythos: hi, is http://pastebin.de/22381 from hp t5[23]35z? and if so, what have you found so far?
<xranby> is there a way i can flag a bug in launchpad that this package needs to get rebuilt? https://bugs.launchpad.net/ubuntu/+source/mplayer2/+bug/921621
<ubot2`> Launchpad bug 921621 in mplayer2 "mplayer: relocation error: mplayer: symbol __aeabi_d2lz, version LIBAVFORMAT_53 not defined in file libavformat.so.53 with link time reference" [Undecided,Fix committed]
<goupilapps> hi, i need help, i cannot connect to nettwork with my pandaboard, with ubuntu
<j_ack> hallo, how do i enable bluetooth on pandabord (ubuntu 1204) .the blootooth i grayed out.
<GrueMaster> goupilapps: Wired or wireless?  I have both working here.  Which Ubuntu release?
<GrueMaster> j_ack: Not sure, haven't looked into it.  Could be a firmware issue, waiting on the TI ppa.
<j_ack> GrueMaster, ok,thank you
#ubuntu-arm 2012-03-20
<sveinse> I'm running natty and every time I reboot, I need to run "sudo update-binfmts --enable qemu-arm" to be able to run armel binaries on intel. Is there a recent policy change disabling these binfmts at every boot?
<Laney> Could someone spare 2 minutes to try a test build on an arm{el,hf} (shouldn't matter) porterbox for me? http://paste.debian.net/160402/
<shadeslayer> rsalveti: poke
<shadeslayer> Laney: I have a armel pbuilder setup, would that work?
<Laney> possibly
<Laney> not sure if ghc will work there, mind
<shadeslayer> ghc? I'm not quite familiar with that acronym
<shadeslayer> Laney: uh, this is for debian? I have a precise armel pbuilder ...
<Laney> ghc is a haskell compiler, and the target distro shouldn't matter
<shadeslayer> ok
<shadeslayer> Laney: uh, I didn't have  haskell-devscripts, it's going to take a bit :)
<shadeslayer> about 10 minutes or so
<shadeslayer> ok so I have a problem where upstream stores double precision values in databases
<shadeslayer> but that won't work on arm obviously
<shadeslayer> so how do I work around databases getting tainted between arch's ?
<shadeslayer> ( the data being stored is geolocation data, seems like it's important to store it in double )
<janimo`> shadeslayer, the ARMv7 processors that Ubuntu runs on have good double precision support
<janimo`> even hardware registers for it :)
<shadeslayer> janimo`: ok weird, then why does the build fail ?
<shadeslayer> lemme get the build log
<shadeslayer> https://launchpad.net/ubuntu/+source/digikam/4:2.5.0-1ubuntu1/+build/3215910
<shadeslayer> https://launchpad.net/ubuntu/+source/digikam/4:2.5.0-1ubuntu1/+build/3215911
<shadeslayer> /build/buildd/digikam-2.5.0/extra/kipi-plugins/photolayoutseditor/widgets/canvas/CropWidgetItem.cpp:343:62: error: no matching function for call to 'qMin(qreal, double)'
<shadeslayer> and ever since I made that to qMin(qreal, qreal) everything works just fine
<janimo`> shadeslayer, that is a Qt programming issue that only occurs on ARM and indeed has roots in ARM traditionally not being good at double precision
<janimo`> qreal is defined as float on ARM and double elsewhere in Qt
<shadeslayer> ok, so for ARM7 and above Qt should now define qreal as double?
<shadeslayer> and this would make it a Qt issue
<janimo`> when qreal and double are used interchangeably that is not an issue (x86)
<janimo`> but when that code gets built on ARM float != double and gcc complain
<shadeslayer> right
<shadeslayer> janimo`: so essentially, qreal needs to be typedef'd to double on ARMv7 and above
<janimo`> I am not sure it is possible anymore to change it back on ARMv7 in Qt, it likely breaks linking with binaries using Qt before the change
<janimo`> so qreal stays float on ARM, but code needs to be careful and use qreal qhen qreal is meant and not use double liberally in its place
<shadeslayer> hmm, yes, but I could report this issue upstream, might be fixed in time for Qt5
<janimo`> shadeslayer, that would be good indeed, Qt5 could be a place to fix this
<janimo`> until then the kde apps using qMin must pass two qreals to that function
<shadeslayer> gotcha
<janimo`> so not identifiers declared as double
<janimo`> lots of KDE or Qt based app have this issue still in Ubuntu and likely upstream
<janimo`> Laney, will check your patch, took a while to get all build-deps sorted in a chroot
<Laney> janimo`: thanks. I think it's straightforward - skein.cabal just doesn't set the define for unknown arches and skein_port.h errors with #error if it isn't set
<janimo`> Laney, I just added that debian/rules change and now waiting for it to finish one way or another
<janimo`> Laney, yes, finished successfully with that change.
<Laney> janimo`: great thanks, uploading to debian now then
<janimo`> Laney, cheers
<janimo`> Laney, no public ARM porter boxes for you to play with when needed?
<Laney> there are, but you have to wait a while for BDs to be installed
<Laney> thought it might be quicker to ask here ;-)
<janimo`> Laney, sure np, just wanted to make sure you are not blocked on this when testing ARM changes ;)
<jadahl> am I supposed to be able to easily install ARM versions of libraries alongside the others on my x86_64 system in Ubuntu 12.04?
<jadahl> my purpose of doing so is cross compiling and running in QVM on the same computer
<infinity> dannf: Your highbank branch ( https://code.launchpad.net/~dannf/flash-kernel/highbank-support ) doesn't include updates to debian/f-k-i.postinst
<dannf> infinity: ok - i'll take a look.
<infinity> dannf: Don't ask why all that code is duplicated, it is what it is. :P
<dannf> infinity: do you know if we'll be rebasing on debian's version at any  point?
<infinity> dannf: Not before precise.
<infinity> dannf: But yes, some day we'll switch.
<dannf> *nod*
<ogra_> :q
<infinity> E37: No write since last change (add ! to override)
<ogra_> hehe
<ogra_> silly unity, alt-tab never gets me where i expect to land
<jadahl> are the repository containing arm packages not under archive.ubuntu.com ?
<ogra_> jadahl, nope, they never were
<infinity> jadahl: ports.ubuntu.com/ubuntu-ports
<jadahl> ah
<ogra_> armhf (and the old armel) are on ports.ubuntu.com
<infinity> (and powerpc)
<jadahl> nice, thanks
<infinity> More easily stated as everything !x86. :P
<rsalveti> GrueMaster: lightdm seems to be quite slow even on panda
<rsalveti> at least while moving the cursor the cpu gets easily consumed
<GrueMaster> rsalveti: I haven't been paying attention.  Working on arm server workload test development.
<rsalveti> after launching unity-2d it works fine, but back to lightdm makes it slow again
<rsalveti> GrueMaster: ok, will open a bug for that
<rsalveti> would like to have perf available to check, but that is another bug
<rsalveti> ppisati: were you able to check the broken perf bug?
<rsalveti> ogra_: infinity: attached a debdiff at bug 959928 with the fix
<ubot2`> Launchpad bug 959928 in xorg-server "Driver fallback for ARM loads the vendor driver twice and gets invalidated with the error" [High,In progress] https://launchpad.net/bugs/959928
<rsalveti> so we can have the pvr driver loaded without a xorg.conf file
<rsalveti> another fix needed to have the working pvr driver at the archive
<GrueMaster> It would be super cool to have the drivers available for Beta 2.  Is this the armhf version?
<rsalveti> GrueMaster: yup
<rsalveti> GrueMaster: I got the drivers already in place, updating the bug in a few
<GrueMaster> awesome.
<rsalveti> would need a review and someone to sponsor
<rsalveti> and this xorg fix to be included as well
<rsalveti> GrueMaster: infinity: ogra_: bug 959924 properly updated
<ubot2`> Launchpad bug 959924 in ubuntu "[needs-packaging] pvr sgx driver and kernel module for Pandaboard" [Wishlist,In progress] https://launchpad.net/bugs/959924
<rsalveti> needs a review and someone to sponsor the packages as well
<rsalveti> just tested and it worked fine here on both 4430 and 4460
<rsalveti> for ARMHF
<ogra_> thx
<rsalveti> once that lands we can also enable the notification for users to install the driver once they install the images
<rsalveti> like what we have for radeon or nvidia
<ogra_> you mean jockey
<ogra_> that will likely require some changes
<rsalveti> ogra_: yes
<rsalveti> ogra_: something on my todo to check
<rsalveti> would be great to have that notification
<rsalveti> and with just one click, boom, sgx working :-)
<rsalveti> and then people can install TI's PPA for a newer driver, with the newer kernel and such
<rsalveti> but the default is already enough to get it to work with opengles applications
<ogra_> yeah
<ppisati> ops
<ppisati> rsalveti: checking it
<rsalveti> ppisati: thanks
<ppisati> rsalveti: it seems it's in the code ($somewhere)
<ppisati> rsalveti: it's not a config issue, and upstream is ok
<rsalveti> ppisati: would be useful to check with jessi and andy, I remember we had a similar issue in the past with 3.1
<rsalveti> might be missing one patch or two
<ppisati> rsalveti: i'll shot them an email then, thanks
<rsalveti> ppisati: great
<jadahl> yay. it's very possible to run arm binaries seamingly under x86_64 (via qemu) just as if they were normal binaries
<jadahl> and install third party libraries into /usr/arm-linux-gnueabi
<ppisati> rsalveti: you mean jesse barker?
<rsalveti> ppisati: http://www.linaro.org/about/meet-the-team/jaswinder-singh/
<ppisati> rsalveti: k
<GrueMaster> Wishlist?  rsalveti, your pvr sgx packaging bug has been marked as a wishlist item.  I would think it is higher importance than that.
<rsalveti> GrueMaster: that's the default for needs-packaging
<rsalveti> afaik
<GrueMaster> ah, ok.
<rsalveti> ppisati: also, can you check why the patches for cross compiling to make it compatible with dkms got reverted?
<rsalveti> ppisati: bug 666267
<ubot2`> Launchpad bug 666267 in linux-ti-omap4 "Cross compiled headers package breaks DKMS compilation" [Medium,Confirmed] https://launchpad.net/bugs/666267
<rsalveti> that's useful for TI, as they want to be able to cross compile the kernel and still be able to use dkms-based packages
<ppisati> rsalveti: becaseu they broke cross-cmpiling in a chroot
<ppisati> iirc
<rsalveti> ppisati: can't we just fix?
<rsalveti> *fix that?
<ppisati> rsalveti: so, these patches fix the DKMS problem ok? i'll see what we can do
<rsalveti> ppisati: great, thanks :-)
<rsalveti> you'll make ti happy with that
<ppisati> rsalveti: will they make my battery last longer in that case? :)
<rsalveti> ppisati: haha, don't think so ;-)
<hstimer> Anyone here using arm server under qemu?
<danboid> If I download the latest precise desktop build can I expect to get a picture out of HDMI on my panda or should I just stick with the server image?
<danboid> (during install)
<danboid> as I presume the desktop builds still don't support serial console output by default?
<GrueMaster> danboid: The desktop images will never support serial console by default, as that is not the nature of desktop images.
<GrueMaster> It has always supported HDMI video.
<danboid> GrueMaster, Hi!
<danboid> GrueMaster, Last time I tried a daily for precise desktop armhf I got no picture via hdmi - not even a fb console
<danboid> GrueMaster, but that was before it was supposed to work
<GrueMaster> That's odd.  I'm running the daily from yesterday, works just fine here.
<danboid> GrueMaster, about 2 weeks ago :)
<GrueMaster> Are you using the hdmi port closest to the usb/nic plugs?
<danboid> yep
<danboid> I'll try the desktop one then
<danboid> it ,ay be fine now
<GrueMaster> Beta 1 also worked.
<GrueMaster> How are you powering your panda?
<danboid> GrueMaster, OK, thats handy to know
<danboid> GrueMaster, 5V 4A PSU
<GrueMaster> ok.  Sometimes I see people having issues when powering over min-usb from a laptop.
<danboid> GrueMaster, Do you know of any interesting apps that support GLES except KDE? What about epsxe?
<danboid> GrueMaster, or any good games of course! :)
<GrueMaster> Not off hand.  I haven't done much testing on that because before now, video drivers were post-release.
<GrueMaster> You could try pts or Open Arena.
<danboid> Yes, Q3 is the only other thing I know of
<danboid> (open arena)
<danboid> I'm hoping epsxe or that other psemu support GLES
<danboid> Thats something I'll be looking into soon
<danboid> I just updated the main ubuntu kernel compilation guide to cater for us arm (Linaro) users btw
<danboid> ie how to know which config file to edit :)
<danboid> is the blaze actually a working cell phone too?
<GrueMaster> I don't know.  Might be.  Not sure if it has 3G or what.
<prpplague> rsalveti: ping
<rsalveti> prpplague: pong
<prpplague> rsalveti: just fyi, i wasn't planning to attend Connect
<prpplague> rsalveti: otherwise i would be happy to present if i were going
<rsalveti> prpplague: yeah, would be nice, but it's a quite long trip
<rsalveti> guess we'll be able to present something at least
<rsalveti> with help of jcrigby
<prpplague> rsalveti: hehe, don't mind the length of the trip, but the $$ , hehe
<prpplague> rsalveti: dandy!
<rsalveti> prpplague: yeah, must be quite expensive, didn't yet check
<rsalveti> prpplague: hopefully we'll be able to show the support for the main boards we're maintaining at linaro
<djshotglass> cheapest arm board i can buy today?
<djshotglass> only needs usb and ethernet or wifi
<rsalveti> djshotglass:
<rsalveti> djshotglass: I'd recommend a beaglebone
<djshotglass> thats almost $100 :/
<djshotglass> i was looking for something like $25
<djshotglass> because i need 4 of them
<rsalveti> then you'd need to grab a raspberry pi
<djshotglass> cant get a rasp for months
<djshotglass> pogoplugs on ebay for $25ish
<djshotglass> hmm
<rsalveti> that might work
<GrueMaster> Just remember that neither pogoplug or raspberry pi will work with ubuntu.
<djshotglass> what why
<rsalveti> yup, you'd need to use debian
<rsalveti> because they are not armv7
<GrueMaster> Ubuntu==armv7.
<djshotglass> meh i can live with that
<GrueMaster> Cheapest armv7 (that I know of) is the beaglebone.  http://beagleboard.org
<rsalveti> you might be able to buy some used beagleboards as well on ebay
<rsalveti> or similar
#ubuntu-arm 2012-03-21
<djshotglass> http://www.ebay.com/itm/260978920665?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649 probably as cheap as it gets eh?
<Riddell> is there really no mailing list to discuss arm issues on?
<lilstevie> Riddell, there is launchpad
<Riddell> lilstevie: mm I know, is there a part of launchpad to discuss arm issues?
<lilstevie> arm issues?
<lilstevie> normally it would be issues with x package
<lilstevie> for any supported arch
<Riddell> well that's not the case I have and there are plenty of other instances where it won't be the case
<Riddell> the existance of an ubuntu server arm list proves that
<lilstevie> so say you had an issue with chromium-browser you would comment against that
<Riddell> I don't have an issue with a package
<lilstevie> what kind of issue is it?
<Riddell> one with arm
<Riddell> really I've tried debugging it on irc more than once before, now I need a mailing list
<suihkulokki> ubuntu-server-arm lists appears to have no traffic
<Riddell> two dysfunctional communities does not a functional community make :)
<suihkulokki> I wonder why anyone bothered opening such a limited-scope mailing lsit
<Riddell> suihkulokki: because of people like me who have questions about arm
<suihkulokki> Riddell: seems like you have got off on the wrong foot today
<suihkulokki> I was just wondering why ubuntu-server-arm rather than say ubuntu-arm
<Riddell> suihkulokki: oh I've been battling arm for two or three weeks now :)
<Riddell> suihkulokki: yes renaming it would be very sensible
<suihkulokki> Riddell: meanwhile, I suspect the list doesn't have many readers so I guess your best bet (if indeed you can't pin your problem to a package) is to blog about it :P
<Riddell> done that already :)
<suihkulokki> oh
<prpplague> GrueMaster: is there a recent "non-unity" ubuntu release for panda?
<ogra_> ubuntu-server
<GrueMaster> Ubuntu-server.
<prpplague> that uses the gnome2 desktop?
<ogra_> gnome2 is dead upstream
<ogra_> ubuntu-server offers you a task selection at the end of the install
<prpplague> ogra_: what does the ubuntu-server edition use instead of unity?
<ogra_> you can pick other desktops there
<prpplague> ahh
<ogra_> server by default doesnt us a desktop
<prpplague> ahhh
<ogra_> but it lets you select one....
<prpplague> ogra_: ahh ok, i'll have a look
<ogra_> alternatively install desktop and install another desktop on it
<ogra_> sudo apt-get install lubuntu-desktop
<ogra_> or xubuntu-desktop
<prpplague> yea
<prpplague> probably stick to an 11 install.... bummer
<ogra_> (note, the server install completely runs on serial)
<prpplague> no worries there for me
<ogra_> sure, just wanted to mention it ... since the desktop one doesnt enable serial at all (after u-boot)
<prpplague> ogra_: are the x86 installs the same?
<ogra_> no
<ogra_> well, content wise they are
<ogra_> the installation is completely different
<prpplague> ogra_: right, that was my vague question, hehe
<ogra_> right, with 12.04 there is only unity on the desktop images
<ogra_> though for x86 there are xubuntu,kubuntu and lubuntu images
<prpplague> thats a real shame
<ogra_> as well as ubuntu-studio and mythbuntu
<ogra_> why is that a shame ? we always only shipped the default desktop
<prpplague> yea, just unity and i don't get along
<ogra_> its not like ubuntu changed that much in this regard
<ogra_> (since CDs didnt magically grow over 800M... )
<suihkulokki> CDs are a lame excuse on arm where nobody uses CDs :)
<prpplague> ogra_: yea, just the choice of unity is my issue. but that is just me
<ogra_> suihkulokki, i didnt refer to arm above :)
<ogra_> prpplague, nah. not just you
 * ogra_ gets along pretty well with unity2d but really bad with unity
 * prpplague needs to clean his work area
<rsalveti> ogra_: did you have time to look at the sgx packages?
<ogra_> rsalveti, no, still busy getting oem-config preseeding to work, they are next on the list though
<rsalveti> ogra_: great, meanwhile I'm trying to fix clutter
<rsalveti> to unblock the arm images
<ogra_> heh, yeah, i saw
<pbuckley> *** VTE ***: Failed to load terminal capabilities from '/etc/termcap'
<pbuckley> after this mornings apt-get dist-upgrade
<gildean> pbuckley: close down open terminals and open them up again
<gildean> iirc the error comes from an updated link and is corrected when open terminals are closed and the new version is started
<highvoltage> hi! ubuntu-12.04-beta1-preinstalled-desktop-armhf+omap4.img should work on a pandaboard right?
<ogra_> img.gz ... but yeah
<highvoltage> (I just get a black screen, where it works fine with a 11.10 armel desktop image)
<ogra_> do you know what board revision you have there ?
<ogra_> we deinitely tested on panda ES and panda A1 and A2
<highvoltage> Pandaboard ES
<ogra_> did you try the "other" HDMI port ? :)
<ogra_> iirc the graphics driver changed, might be that you need to use the DVI port now
<highvoltage> it's on the one marked DVI (since I'm susing it with a DVI adaptor)
<highvoltage> let me try the other one...
<GrueMaster> ogra_: No, hdmi port (closest to the USB/Mic ports) should be fine.
<GrueMaster> That would be it.  Switch ports.
<GrueMaster> Only diff is that the HDMI port is dvi-0 and has digital audio signals.
<highvoltage> indeed, I switched to the other one and it works :)
<GrueMaster> Excellent.
<highvoltage> with 11.10 it only worked on the other one.
 * highvoltage wonders if update-manager can plug out a cable and plug it into another port :p
<ogra_> highvoltage, sure, but you need to buy the HW extension in the canonical shop
<highvoltage> I'll look out for it! I hope it has unnecessaryly elaborate robotic arms
<ogra_> it comes with a free bumper sticker even !
 * highvoltage is afraid to ask what it says
 * ogra_ isnt that creative anymore after a 11h day (that still has 2h to go)
<highvoltage> (same here, I was close to getting to a "I â¥..." something about sabdfl but my brain can't formulate funny anymore
<highvoltage> (at least it can still do unicode)
<ogra_> heh, more than i can :)
<highvoltage> what's in the server image that makes it so much bigger than the desktop one?
<GrueMaster> Lots of preseeded packages for server installation.
<GrueMaster> So that you don't need to install them from the net.
<GrueMaster> (in theory)
<highvoltage> ah
<pbuckley> its to bad in unity when you click the ubuntu logo in the upper left hand corner and you get that black search box pop up that when i type in a url like afp://bobs_fileshare/jokes or smb://janes/pics it doesnt take me to the network file share..
<highvoltage> ogra_: when I do an apt-get autoremove after my pandaboard is installed, it removes dpkg-repack, apt-clone, libdebian-installer4 and a few other things that doesn't quite seem like they belong in the final installation
<highvoltage> ogra_: am I mistaken or should I file a bug for that?
<ogra_> yeah, file a bug
<dannf> infinity: my f-k branch is now updated w/ f-k-i changes for highbank
<zma> How to get usb networking on Ubuntu 11.10? If I try ordinary steps, I get error that there is no such interface as usb0.
<zma> By ordinary I mean I make sure modules cdc_ether and usbnet are loaded, make entry to /etc/network/interfaces for usb0 and then /etc/init.d/networking restart
#ubuntu-arm 2012-03-22
<highvoltage> is it normal for Ubuntu ARM builds to depend on having busybox in the initramfs? I disabled it and then I got a kernel panic on "init: grep: not found"
<GrueMaster> highvoltage: Yes, it is.  All of the premount init scripts need it to run.  If you don't want that, don't use initrd.
<ogra_> erm, *all* ubuntu initrds depend on busybox
<ogra_> its the default shell in the initrd
<ogra_> nothing arch specific with that
<highvoltage> ogra_: I usually disable busybox in my initrds on ubuntu machines and they work just fine
<highvoltage> (at least they appear to)
<ogra_> well, how exactly do you disable it ?
<ogra_>   /init in the initrd is a shellscript
<ogra_> and the only shell shipped in initrd is busybox
<ogra_> (also all local-top/bottom/premount scripts are shell)
<ogra_> you probably found an arm specific bug
<ogra_> (i.e. that it is actually disableable while that option is ignored on other arches or some such)
<janimo`> highvoltage, have you switched to ARM lately :) ?
<janimo`> are you on a quest for lowpower thin clients?
<highvoltage> janimo`: I don't really switch to anything. I just assimilate, like the borg :)
<janimo`> borg needs arms too
<highvoltage> indeed.
<GrueMaster> ogra_: Can you review my change to lp:ubuntu/flash-kernel (lp:~gruemaster/flash-kernel/bug-961174)?  Thanks.
<ogra_> GrueMaster, hmm, that somewhat defeats the purpose of Env.txt etc, shouldnt they override boot.scr ?
<GrueMaster> That's the problem.  Apparently, Orchestra  (or some provisioning tool) uses those, but our images don't.
<GrueMaster> So if you use that tool to tell a system to do a netboot install, the boot partition never gets overwritten.
<GrueMaster> Maybe it should go in f-k-i?
<ogra_> well, its still wrong imho
<ogra_> if some tool puts a broken file in the way it should also move it away
<ogra_> if a user puts such a file there it should do what its supposed to do
<ogra_> (override the system default)
<ogra_> f-k-i would surely be a better place but my complaint still  stands even there
<GrueMaster> The other issue (as I understand it) is if it exists and bricks the system (i.e. won't boot), you can't recover via usb boot.  For remote deployments, this will be a problem.
<ogra_> right, still, the questions are a) why does it exist at all (why isnt boot.scr used) and b) why is its content broken
<ogra_> if we would rm the file or mv it like you do we prevent the user from using a documented override mechanism (and imho *introduce* a bug)
<ogra_> GrueMaster, can you ask rbasak why that file exists at all, why its broken in the bug ?
<ogra_> removing it isnt the proper solution
<rbasak> ogra_: because it's been created by a previous tenant
<ogra_> since that would make the overriding impossible
<ogra_> the purpose of this file is to give the user an easy way to modify boot settings ...
<ogra_> if your tool uses that on a system level, fix the tool to use the system file please
<ogra_> breaking behavior for the use cant be a solution to this bug
<rbasak> ogra_: When I install Ubuntu on an Intel machine, I expect the installer to override whatever the boot configuration was previously. If the MBR was set up to boot Windows, after running the installer and confirming that I want the boot configuration changed, I expect the system to boot Ubuntu.
<rbasak> ogra_: if you want to override this, you change the boot configuration _after_ running the installer but before booting into the new system
<ogra_> if you install on an intel system you have various possibilities to override the bootloader settings
<rbasak> ogra_: I don't see why the behaviour on a Pandaboard should be any different
<mahmoh> so that's not entirely true, you can add info. to grub for boot specifics which I don't think you can with u-boot/boot.scr at the moment
<rbasak> If you want to override the boot, then tell the installer that you don't want to run flash-kernel-installer
<ogra_> if you use u-boot the only way to i.e. ebnable a serial console in the kernel cmdline is to put an uEnv.txt in place
<ogra_> or to fiddle with the provided boot.scr ...
<mahmoh> righjt
<mahmoh> right
<ogra_> the .txt files were enabled for easier overriding through user action
<ogra_> if you have any tool using that machanism, make it better use boot.scr
<rbasak> What you have in there at the moment is a hack which is preventing the installer from doing its job properly. What I want is for the installer to work in all cases. If you want to add a hack later, then please don't break my use case!
<ogra_> i dont want to add any hacks at all
<rbasak> It is necessary for the installer to be able to erase any configuration left by a previous tenant
<ogra_> if your use case usues a user definable file to set system settings your use case does it wrong
<ogra_> thats like having a package put a used rule into /etc/udev/rules.d
<ogra_> instead of using /lib/udev/rules.d
<rbasak> My use case requires a machine to be able to be reinstalled regardless of what was there before
<ogra_> you wouldnt use /etc in that case either
<rbasak> Orchestra needs this too.
<ogra_> still you make use of a user override mechanism on a system level
<rbasak> I'm not making use of anything
<ogra_> use the system mechanism for this
<rbasak> The user leaving a uEnv.txt is a DoS
<rbasak> I'm not using it
<ogra_> well, who puts the .txt file in place ?
<ogra_> the one that got in your way i mean
<rbasak> Somebody who has root on the machine before I remotely decide to wipe and reinstall it to give it to someone else who has root on the machine.
<infinity> DoSing yourself isn't a DoS.
<ogra_> rbasak, if there is a way that we can know we are in such an environment, i'm happy to add a hack for that specific env
<infinity> Maybe it would be nice if d-i detected this odd situation and asked about it, but this isn't "just like ovewriting a windows MBR", and it would be best to not pretend it was.
<GrueMaster> I think the root of the problem is that partman currently doesn't reformat the boot partition during netinstall.
<ogra_> breaking documented override behavior for everyone cant be the solution for a corner usecase
<rbasak> ogra_: how about a preseed option to say "override any user overrides"?
<GrueMaster> Known bug.
<ogra_> rbasak, that sounds saner at least
<rbasak> ogra_: if it sees that then it will either delete uEnv.txt or *.
<rbasak> infinity: it's not "yourself", it's a previous tenant DoSing a future tenant. Imagine if your EC2 instance didn't come up because a previous user left a file somewhere.
<ogra_> i'm not opposed to hacks (if you ask others they might call me the master of bad hacks even) ... but i'm opposed to break user abilities for providing their own defined overrides at install time
<rbasak> ogra_: I think you've got the sense inverted. If the user wants to define an override at install time, he should say so using debconf!
<ogra_> thats not possible on a u-boot level
<infinity> rbasak: Root is you.  Calling yourself a "tenant" doesn't change things.  There are a number of ways I can mess up an Intel system for the next person I sell it to as well.
<infinity> rbasak: And the "boot partition" on firmwareless SD system (ie: a Panda) is more akin to the BIOS than to a disk MBR.
<infinity> dannf: f-k highbank changes sponsored.
<infinity> dannf: Do you have a sane way to test this once it's in the archive?
<ogra_> GrueMaster, bug 848782 looks suspiciously like a duplicate of bug 921137
<ubot2`> Launchpad bug 848782 in flash-kernel "Serial console not enabled for passphrase prompt when using LUKS" [Medium,In progress] https://launchpad.net/bugs/848782
<ubot2`> Launchpad bug 921137 in flash-kernel "Flash-kernel-installer doesn't support d-i debian-installer/add-kernel-opts in preseed " [Undecided,Confirmed] https://launchpad.net/bugs/921137
<GrueMaster> Similar, but slightly different.
<infinity> They can both be fixed in the same way, I think.  I had a local branch for that and got sidetracked...
<ogra_> well, i dont see any solution for 848782 apart from using add-kernel-opt
<ogra_> s
 * infinity wonders where that went.
<ogra_> that you use LUKS doesnt reallys imply that you use a serial console, that needs to be specified anyway
<ogra_> (luks could indeed preseed that value if it knows there is only serial)
<infinity> Nah, it should just do the same thing grub-installer does here.
<infinity> And, like I said, I was working on that.  Tobin and I discussed it a while ago.  I just got sidetracked with other stuff and let it slip. :/
<ogra_> ah, k
<ogra_> the discussion above made me look at the f-k buglist :)
<infinity> ogra_: So, I fixed all the *sums generation for all the images... Except for ac100.bootimg.  Were you doing something abnormally hackish in how you deal with that?
<ogra_> not that i can think of
<infinity> Hrm.
<infinity> I'll have to investigate that further.
<infinity> But at least the big images are all right now, which was the major concern.
<ogra_> look at the debian-cd code, i just added the .bootimg type to the file types
<ogra_> it isnt generated as .raw like the others though, since it comes directly out of live-build iirc
<ogra_> probably that gets in our way
<ogra_> feel free to leave that issue to me though
<ogra_> (not today anymore, but I can look at it before B2)
<infinity> Yeah, it comes from live-build, same as manifest and other files.
<infinity> It could just be exposing some weird assumption in cdimage, given than this is the only image that produces two files that need summing.
<ogra_> yeah
<infinity> I could probably paper over it by making debian-cd sum the bootimg files, but I'd like to figure out why cdimage is doing it wrong.
<ogra_> iirc cdimage does it while renaming them from .raw to their actual filetype
<ogra_> or do i remember wrong ?
<infinity> No, cdimage does it after the rename.
<ogra_> ah
<infinity> But then maps certain extensions back to .raw, so it can match against the *SUMS in scratch.
 * ogra_ through its the same function in the makefile
<infinity> bootimg doesn't get mapped though (which is correct), so...
<infinity> I wonder how much of this mess I need to replicate to iterate through some local testing.
<ogra_> pfft, just do it on nusakan and revert it if it breaks
<ogra_> thats why we have it all in bzr :)
<dannf> infinity: cool - yeah, just qemu though
<infinity> ogra_: :P
<infinity> ogra_: Not doing it in production for the obvious "don't work in production" reasons, but mostly, I want to reduce this to a small enough test that I can do it in seconds, not hours. :P
<ogra_> ah, yeah
<ogra_> still, relpicating cdimage loacally cries for pain
<infinity> Oh, I've done that before.
<infinity> But in this case, it's reducing, not replicating.
 * ogra_ too, thats why i said that
#ubuntu-arm 2012-03-23
<ogra_> rsalveti, pvr drivers uploaded to NEW, talk to infinity for an archive admin review to get them out there ;)
<GrueMaster> ogra_: Know any logical reason why the arm team was assigned bug 856988?
<ubot2`> Launchpad bug 856988 in gstreamer0.10 "totem cannot play quicktime file after upgrade to oneiric" [High,Confirmed] https://launchpad.net/bugs/856988
<GrueMaster> Bug was filed against amd64.  Not a single arm reference in the bug that I saw.
<ogra_> just unassign it
<ogra_> seriously not an arm prob
<NCommander> GrueMaster: with apt-setup, my test failed, and I'm not sure why, I'll stab it more in my today
<ogra_> GrueMaster, i pinged kate about it, she will look after the meeting why she assigned it to arm
<GrueMaster> She probably wanted the ubuntu-audio team.
<ogra_> or -desktop since i see that seb did set the importance already
<ogra_> we'll hear after the meeting i guess ;)
<GrueMaster> Oh, beta 2 has opened up in the iso tracker.  Guess I can shut down the daily image tests I have automated.
<jimerickson> not getting any hdmi output after todays update.
<Riddell> ogra_, GrueMaster, Daviey: bug 961133 updated with logs from today's image
<ubot2`> Launchpad bug 961133 in linux "Ubuntu Desktop ARM Images do not boot on my Pandaboard ("EXT3-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)")" [Medium,Confirmed] https://launchpad.net/bugs/961133
<ogra_> Riddell, looks all proper, are you sure you have the monitor plugged in to the right port ?
<ogra_> (try changing them for a test)
<ogra_> it definitely boots and also seems to do the reboot after resizing the FS just fine ... theoretically it should now sit with ubiquity on the screen
<Riddell> ogra_: no I'm not sure because I have had inconsistent advice from this channel and from tests, it works with the DVI port with oneiric images.  ubuntu server requires the HDMI port
<GrueMaster> ubuntu server is headless.  Doesn't care about video ports.
<ogra_> well, just pulg it over to the other port, i'm never sure which one the kernel driver supports in which TI kernel
<ogra_> right, server runs on serial
<GrueMaster> (kernel might).
<ogra_> Riddell, in any case that looks like a successful boot
<ogra_> if there are issues i would blame the graphics driver ot the monitor
<ogra_> s/ot/or/
<Riddell> ogra_: and yet it's not
<ogra_> ??
<ogra_> not what ?
<Riddell> ogra_: the graphics driver works fine with ubuntu server precise and ubuntu desktop oneiric
<Riddell> not successful
<ogra_> so what do you see on the screen then between the two u-boot runs i see there ?
<Riddell> ogra_: there is no output to the monitor
<ogra_> how long does it take approximately beweeen the two boot runs ? and does the left LED blink in a consant ~1sec fequency after it sits there on the serial ?
<Riddell> I don't know, I haven't timed it, would it help you if I did?
<ogra_> the reszizing run usually takes about 1-2min, then it reboots (note that only happens once if you first boot a new image)... if after that you see the left LED blink constantly it means that everything is fine but the screen doesnt output
<Riddell> I don't know which is the left LED but one LED is currently doing two blinks in rapid succession then about 1 sec off
<ogra_> sounds about right
<ogra_> it has definuitely to do with the graphics/monitor
<Spider-Pork> hi, i need to edit boot.script and then get the boot.scr. What should I do? Thank you
<ogra_> what kind of monitor is that ?
<Riddell> ogra_: acer DVI
<ogra_> Spider-Pork, already installed image ?
<ogra_> Riddell, is it capable of doing 720p and 1080p modes ?
<Riddell> ogra_: I don't know what that means
<ogra_> do you know which modes it supports ?
<Riddell> ogra_: no
<Spider-Pork> ogra_: yep
<Spider-Pork> ogra_: i need to enable DVI output
<Spider-Pork> as reported here http://omappedia.org/wiki/PandaBoard_FAQ#How_do_I_enable_DVI_output.3F
<ogra_> the graphics driver reads the monitors EDID usually, if it doesnt find modes it can support it can actually fall over
<ogra_> Spider-Pork, after you edited /boot/boot.script, just run sudo flash-kernel
<ogra_> it will update boot.scr
<Spider-Pork> cool thank you
<Spider-Pork> my problem now is that i can't log in with X  :)
<Spider-Pork> i can't see no output on my DVI monitor
<ogra_> Riddell, when you used the precise server image, did you actually see anything before X came up ? (plymouth ... console etc)
<Spider-Pork> before apt-get install omap4-extras was connected to HDMI
<Spider-Pork> but after upgrade i can't see anything on HDMI
<Riddell> ogra_: no I had to start X from the serial command line
<GrueMaster> Riddle;  What monitor do you have?  What are the specs?
<ogra_> Riddell, aha, sounds like an issue with the framebuffer driver and your monitor
<Riddell> GrueMaster: this one http://search.acerdirect.co.uk/acer/V223hqv
<ogra_> Riddell, between oneiric and precise the graphics driver was cvompletely redone by TI, that might explain your issues (though i would still love to know where your weird bootmessages came from when you fiddled with the image)
<ogra_> Riddell, talk to robclark if he knows anything about issues with that monitor (he maintains the graphics stack and we actually know that some monitors and brands dont work well at all)
<Riddell> ogra_: robclark is a TI guy?
<ogra_> yes
<GrueMaster> Looking at the specs for that monitor, It is 1920x1080 (HD 1080).  But, port wise it only lists vga.  Does it have DVI & HDMI?
<ogra_> Riddell, and about your complaint that it is hard to install ubuntu on panda, 100s of other users dont have any probs at all ;)
<Riddell> GrueMaster: DVI yes, HDMI no
<ogra_> right, intrestingly http://www.acerdirect.co.uk/ACER_55cm_21.5_Wide_16_9_FHD_5ms_20000_1_ACM_black_MPRII_EURO-UK_EMEA_200ni_ET.WV3HE.017/version.asp says 0 for DVI and HDMI ports
<GrueMaster> As to today's image, I am not getting video either.  Until that gets sorted, please stick with beta 1.
<robclark> Riddell, the display part should be largely similar..  but I'd start w/ just trying to get fbcon (ie. text) up, without yet starting x..
<robclark> drm.debug=7 in bootargs, and pastebin the boot log would be helpful
<Riddell> robclark: what is fbcon?
<robclark> ie. text console
<GrueMaster> You can use today's ubuntu-server image for this test.
<Riddell> GrueMaster: why is that better?
<robclark> or just put "text drm.debug=7" in your bootargs
<ogra_> right, it shoudl come up with a framebuffer console after install and show you a login prompt onm the screen
<jimerickson> GrueMaster: am not getting any hdmi output after todays update either.
<ogra_> Riddell, because you cant run the desktop installer without a screen
<Riddell> boot args are set like that? http://omappedia.org/wiki/PandaBoard_FAQ#How_do_I_saveenv_for_boot_args_on_a_PandaBoard.3F
<ogra_> Riddell, just run through the server install, then edit /boto/boot.script and change the bootargs there ... then you run sudo flash-kernel and reboot
<GrueMaster> robclark: THis might be an indicator:  sysfs: cannot create duplicate filename '/devices/platform/omap/omapdss_dss'
<ogra_> oh
<robclark> hrm?
<ogra_> s/boto/boot/
<robclark> how can that happen?
<ogra_> wasnt there a fix from rsalveti for exactly such an issue ?
<GrueMaster>  One sec and I'll pastebin a dmesg.
<robclark> maybe, I've not seen that before
<ogra_>   * debian/patches/111_armel-drv-fallbacks.patch:
<ogra_>     - Avoid loading the driver to test if it's available. Xorg will later load
<ogra_>       and validate the module, and if it's already loaded it'll trigger an
<ogra_>       error and invalidate the driver (LP: #959928)
<ogra_> though i think that was focusing on pvr
<GrueMaster> http://paste.ubuntu.com/896634/
<Spider-Pork> ogra_: I done the steps you suggest to me. Now the board won't boot
<GrueMaster> dmesg log from my ubuntu-server install (preseeded btw - woot!)
<ogra_> Spider-Pork, well, i have no idea about the omappedia stuff, we otften have people that follow outdated stuff from there, what exactly did you change in your boot.script ?
<robclark> hmm, do we somehow end up with two omapdss platform devices?  That would cause all hell to break loose...
<Spider-Pork> ogra_: as suggested here http://omappedia.org/wiki/PandaBoard_FAQ#How_do_I_enable_DVI_output.3F I added "omapdss.def_disp=dvi" at the end of the file
<ogra_> no idea if that works or not with the current images
<Spider-Pork> the problem is that don't boot
<Spider-Pork> the SD card led are dead
<Spider-Pork> SD card and run led
<ogra_> and you definitely only added that arg and properly ran flash-kernel after that ?
<Spider-Pork> yep
<ogra_> sounds like your boot partition is trashed somehow ...
<Spider-Pork> cool
<ogra_> this was an official ubuntu image ?
<Spider-Pork> fortunately I got a safe copy of boot.scr
<ogra_> (downloaded from cdimage.ubuntu.com)
<Spider-Pork> ogra_: yep
<robclark> fwiw, I'm not sure, all the legacy omapfb bootargs are ignored, omapdss bootargs, not sure if they could have some unintended result..
<Spider-Pork> https://wiki.ubuntu.com/ARM/OMAP
<ogra_> i dont think its your boot.scr
<robclark> omapdrm will just use any/all displays that it detects a connection on
<ogra_> if the LEDs dont light up the bootloader (MLO) is not found ... if your boot.scr would be trashed it would still boot into a bootloader session
<Spider-Pork> oh well, 3 hours of ubuntu installation and upgrade in the trash
<ogra_> did you install any third party stuff ?
<Spider-Pork> only omap4-extras
<ogra_> an ubuntu install usually doesnt take more than 20min on the panda
<Spider-Pork> for video acceleration
<Spider-Pork> the installation yep
<Spider-Pork> but the upgrade ...
<ogra_> using the icon on the desktop ? or following some weird omappedia docs again ?
<Spider-Pork> http://omappedia.org/wiki/Ubuntu_PPA
<ogra_> sigh
<Spider-Pork> with shell command
<Spider-Pork> I apologize if I followed wrong guide. What link should follow?
<ogra_> you shoudl just click the TI icon on the desktop
<ogra_> (note that this only is available on released images, for 12.04 there is no working GLES driver yet)
<Spider-Pork> I'm using 11.10
<ogra_> well, there you have the TI icon on the launcher after first boot
<ogra_> it does all you need
<Spider-Pork> OK, I'll reinstall the whole prebuild image
<ogra_> (and the person who added the sed command to that wikipage to trash your sources.list should be smacked ... this should rather link to the launchpad documentation for enabling PPAs)
<Spider-Pork> ah ok :)
<Spider-Pork> image i took here are ok? https://wiki.ubuntu.com/ARM/OMAP
<Spider-Pork> *images
<ogra_> https://wiki.ubuntu.com/ARM/OMAP has links to ubuntu wikipages that document enabling the PPA and the like
<ogra_> or the respective subpages have, cant remember ...
<ogra_> yeah, folllowing the ubuntu wiki should generally get you everything working
<ogra_> at least for released images we test and verify the docs and images every time before release
<Spider-Pork> ok so I'll follow that guide, thank you
<ogra_> :)
<Riddell> Daviey: today's ubuntu server image gives me 100s of lines like this: Use of uninitialized value $value in substitution (s///) at /usr/share/perl5/Debconf/Format/822.pm line 65, <$__ANONIO__> line 23345.
<GrueMaster> Riddell: Where are you seeing that?
<Riddell> GrueMaster: "today's ubuntu server image"
<GrueMaster> can you be a little more specific?  As in "I am not seeing this anywhere, but would like to try to reproduce it".
<Daviey> Riddell: Can you provide more before/after logging.
<Daviey> on a call.. will investigate shortly after
<Riddell> GrueMaster: booted the server image, it did the resizing fine, on second boot I get that message repeated indefinately
<GrueMaster> ogra_: btw:  using your boot.scr & preseed.cfg, system booted straight through to login w/o human intervention.
<GrueMaster> Riddell: I am not seeing that at all.
<GrueMaster> Can you double check your md5sum on the image?
<GrueMaster> Also, try blanking and reflashing the SD (in case it has some corrupted bits).
<Riddell> GrueMaster: 4b7d83d50edd57024bcc370ecb248224  precise-preinstalled-server-armhf+omap4.img.gz
<ogra_> GrueMaster, cool, well, i tested it, so i would be surprised if it would stop working within two days ;)
<GrueMaster> ogra_: Only issue I have is it doesn't pull the hostname.  I'll double check my preseed though.
<ogra_> did you put in a hostname actually ?
<ogra_> the original pressed you added didnt have one
<ogra_> (it used the system fallback in the preseed ... which would be localhost)
<GrueMaster> d-i netcfg/get_hostname string unassigned-hostname is what netboot uses.
<ogra_> right, that means "use the default"
<ogra_> if you set foo instead of unassigned-hostname it should set it to foo
<GrueMaster> I thought it would get it from dhcp.  Maybe I am using a boot cmdline for that.
<ogra_> hmm, probably another bug we need to hunt down
<ogra_> i thought it uses the system default, but dont quote me on that
<GrueMaster> Might be a d-i thing.
<Riddell> robclark: here's the serial output from adding drm.debug=7 http://paste.kde.org/445214/
<Riddell> is that what you mean by boot log?
<robclark> Riddell, hmm, you might need some loglevel=10 or something like that.. so that we actually see the traces..
<robclark> or just try and run dmesg
<robclark> (if the kernel is built w/ large enough log buffer we might not loose the traces we want to see)
<Riddell> robclark: http://starsky.19inch.net/~jr/tmp/dmesg
<robclark> oh, and you need to add drm.debug=7 in bootargs
<robclark> looks like that is still missing
<Riddell> robclark: http://starsky.19inch.net/~jr/tmp/dmesg any better now?
<robclark> Riddell, yes, much..
 * Riddell wanders off in hunt for other monitors to try
<robclark> hmm, what was the issue now?  Looks like it finds and configs hdmi for 1080p..
<Riddell> robclark: the monitor does not show anything
<robclark> hmm..
<Riddell> robclark: I have a DVI-D monitor which is plugged into the HDMI port
<robclark> oh, I think you need to add one more bootarg..
<robclark> you are missing console=tty0
<robclark> (you should have two console='s
<robclark> )
<Riddell> works fine manually installing ubuntu-desktop and starting lightdm from login
<GrueMaster> Also, what image is this?  Beta 1?  It isn't the same issue as the daily image.
<Riddell> (from an ubuntu-server image)
<Riddell> GrueMaster: it is ubuntu server beta 1
<Riddell> works fine with oneiric plugging the same monitor into the DVI port
<robclark> well, at least the display part looks ok.. if you add the second console= you should see boot console on screen as well..
<robclark> I'm not sure about lightdm, etc..  I'm using 12.04 but hadn't updated for a week or so, so I guess I'm not on latest
<Riddell> well that just starts X
<Riddell> anyway starting again with an ubuntu server install to try the console= thing
<robclark> fwiw, might be quicker to just change bootargs..
<robclark> ctrl-alt-f1, see if that can switch you to another VT
<robclark> (if you have no other way to login and edit boot.script and flash-kernel)
<Riddell> alas I already started wiping the card in preparation for going hunting monitors
<robclark> heheh, ok
<Riddell> robclark: is DVI the right port for oneiric and HDMI right for precise?
<GrueMaster> Riddell: I only test on HDMI.  Since Maverick.
<robclark> GrueMaster, Riddell, in theory which ever one is plugged in should work..
<GrueMaster> (I do test DVI occasionally, but not as default).
<robclark> maybe not a bad idea to test.. but it works for me w/ upstream (linus's tree) kernel
<Riddell> why does it have two if DVI monitors can work with HDMI ports?
<rsalveti> hdmi is known to work
<rsalveti> ogra_: thanks
<GrueMaster> Dual monitor support maybe?
<rsalveti> Riddell: is this the issue that is happening just after the latest upload?
<robclark> Riddell, to confuse people about which one to plug in :-P
<robclark> (just kidding)
<rsalveti> might be some conflict with the upstream changes
<rsalveti> I need to check with the latest kernel
<rsalveti> one upload was to sync with ti lt's 3.2 tree
<rsalveti> and another to sync with ubuntu's changes and stable updates
<GrueMaster> rsalveti: I think he is seeing other issues.  But the daily desktop does have a separate issue.
<GrueMaster> rsalveti: See http://paste.ubuntu.com/896634/
<GrueMaster> No video out.
<Riddell> rsalveti: no
<Riddell> why would minicom be giving me this corruption? http://paste.kde.org/445262/
<rsalveti> GrueMaster: yeah, that's the one I saw a bug for
<rsalveti> GrueMaster: can check that
<GrueMaster> Riddell: That looks like bug 924399.
<ubot2`> Launchpad bug 924399 in ubiquity "oem-config-debconf window size issue on keyboard selection screen" [Low,Confirmed] https://launchpad.net/bugs/924399
<rsalveti> did you get the same behavior with screen?
<Riddell> rsalveti: who me?
<Riddell> GrueMaster: my screen looks not very much like that screenshot, no colours and the non US ascii characters are all garbled
<rsalveti> Riddell: yeah
<GrueMaster> Riddell: Minicom doesn't look the same as screen.
<Riddell> rsalveti: I don't run screen, are you suggesting I run minicom inside a screen session?
<rsalveti> no, just open screen directly instead minicom
<Riddell> GrueMaster: well no, what does screen have to do with it?
<GrueMaster> Riddell: screen /dev/ttyUSB0 115200.
<Riddell> ah
<GrueMaster> for one, it displays differently.
<Riddell> this experience really does remind me of linux on a PC a la 1999
<Riddell> robclark: added console=tty0 nothing on monitor
<robclark> Riddell, if you still have "quiet splash" in bootargs, drop that and replace w/ "debug" (and possibly "text" if you don't want x to start)..
<Riddell> how do I save the output with screen?
<GrueMaster> robclark: Is there a way to see what his system reads for edid?
<GrueMaster> Riddell: <ctrl>-A, H
<robclark> GrueMaster, drm.debug=7.. will enable enough  traces to see the edid parsing.. (which looked  fine, btw)
<GrueMaster> That should toggle logging on/off.
<GrueMaster> robclark: ok.
<Riddell> GrueMaster: that only saves what is currently on my terminal not the scrollback
<GrueMaster> Riddell: What do you need in scrollback that you can't reproduce with your console history?
<GrueMaster> (i.e. running dmesg again).
<Riddell> GrueMaster: with screen I have no console history
<GrueMaster> up arrow?
<Riddell> um that depends on the context in which it is pressed
<Riddell> there is no ability to use konsole's scroll function when running screen
<GrueMaster> This I am painfully aware of.
<Riddell> robclark: http://starsky.19inch.net/~jr/tmp/dmesg updated with quiet splash changed to debug
 * Riddell goes in hunt for monitors again
<robclark> well, looks like it is detecting the monitor, and parsing edid fine..
<robclark> so I don't think another monitor would help..
<robclark> from text console, try (possibly as root):  cat /dev/urandom > /dev/fb0
<robclark> should produce snow/noise on the display
<Riddell> robclark: well another monitor did not help
<Riddell> http://starsky.19inch.net/~jr/tmp/dmesg-chris
<Riddell> robclark: cat /dev/urandom > /dev/fb0 does nothing
<robclark> oh, btw, if dvi doesn't work, I expect this is the reason:
<robclark> omapdrm omapdrm.0: dvi has no driver.. skipping it
<robclark> for hdmi, looks like there is some PM issue:
<robclark> [    5.430938] Failed to start PHY
<robclark> [    5.434265] omapdss HDMI error: failed to power on device
<robclark> not sure if there were recently some kernel updates?
<robclark> I do get something like that the very first time I try to power on HDMI, but on upstream kernel don't have all the other hdmi errors..
<robclark> my guess is that tomi fixed something, and the fix isn't backported to ubuntu kernel..
<robclark> at omapdrm level, all looks as it should be, no EDID or hot plug detect or similar issues
<Riddell> mm
<Riddell> ogra, GrueMaster: is there any arm guy in canonical in britain that I could meet up with to debug in person?
<Riddell> e.g. in millbank?
<robclark> Riddell, maybe give a try w/ the linux-ti-omap from ppa:tiomap-dev/omap-trunk ?
<robclark> it is 3.3 based.. and the shape of omapdss has been steadily improving over last few kernel release cycles
<Riddell> robclark: so I just add that PPA and install linux-ti-omap and that's all it needs?
<robclark> I think so
<robclark> I'm usually rebuilding kernel manually myself, but I think the one from the ppa should work (ie. not depend on anything else)
<Riddell> http://starsky.19inch.net/~jr/tmp/dmesg-hdmi-projector  dmesg when plugged into hdmi projector
<robclark> this stuff is very funny looking:  sysfs: cannot create duplicate filename '/devices/platform/omap/omapdss_dss'
<robclark> something is a bit odd about that kernel, not sure if a bad merge of some patch or something??
<robclark> Even back in 3.2 days, I didn't see stuff like that
<Riddell> linux-ti-omap4: Installed: 3.3.0.1481
<Riddell> http://starsky.19inch.net/~jr/tmp/dmesg-linux-ti-omap4-3.3.0.1481
<Riddell> no change
<Riddell> I do believe I have now lost the will to live
<Riddell> oh my god
<Riddell> it works
<Riddell> just in time to save my life
<Riddell> of course it doesn't work on the HDMI port, that would be too consistent
<Riddell> it only works on the DVI port
<Riddell> ogra, GrueMaster: well I have found a solution to bug 961133
<ubot2`> Launchpad bug 961133 in linux "Ubuntu Desktop ARM Images do not boot on my Pandaboard ("EXT3-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)")" [Medium,Confirmed] https://launchpad.net/bugs/961133
<Riddell> ogra, GrueMaster: who do I poke to get that backported?
<GrueMaster> Not sure.  Part of the problem is that yours is a very isolated situation.  Have you been able to get video from the HDMI port on any previous image (Oneiric, Angstrom test image, etc)?  As I said earlier, I test the HDMI port almost exclusively as it is the default port.
<GrueMaster> Now there is a possibility that the precise kernel has issues with the dvi port, I just haven't had the cycles to test tat use case.
<GrueMaster> I am more concerned that you don't have HDMI, as that could indicate a defective board.
<Riddell> well I'm out of lifeforce for today, if you have suggestions on how I can help more do let me know (such as finding other people in britain I can meet to debug with)
<GrueMaster> If you can't get HDMI working with the images I suggested, my next suggestion would be for you to bring your board to UDS where I can test it directly, and possibly swap it for one of mine that is known to work.  Unfortunately, My status of UDS is uncertain at this moment.
<Riddell> GrueMaster: yeah that's what I'll do but it would be nicer to be able to meet up with someone with the skills and hardware sooner
<Riddell> slangasek: sladen is suggesting you will know such people ^^
<GrueMaster> Outside of IS, I don't know of any internally.  Externally, I'm sure Linaro has people.
<slangasek> Riddell: hi, skills and hardware for what?
<Riddell> slangasek: for getting a working pandaboard
<infinity> Riddell: I've not been paying attention here, but how on earth did we decide that your inability to mount a rootfs was a video driver ug?
<infinity> s/ug/bug/
<Riddell> infinity: because ogra decided my previous advice on editing the boot files was incorrect and that was his next idea
<infinity> That error looks like what you'd see if you try to mount ext4 as ext3, though no idea how that would affect you, and only you.
<infinity> Riddell: Or, was that error with some whacky modified bootfiles that forced rootfstype to ext3?
<Riddell> maybe
 * Riddell goes to make dinner with the last scrapes of his lifeforce
<GrueMaster> infinity: I think what happened is he somehow clobbered his boot.scr, and that was the default boot environment from u-boot.
<GrueMaster> I would have to reboot a system here and poke around in u-boot to confirm.
<GrueMaster> As to his hdmi not working, up until today's image I would suspect a hardware issue.  Everything up to today has worked fine for me and others on this channel.
<GrueMaster> rsalveti: I filed a bug for today's video issue.  Didn't see anything in LP prior to mine.  Bug 963512.
<ubot2`> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed] https://launchpad.net/bugs/963512
<rsalveti> GrueMaster: ok, thanks
<rsalveti> need to run a bisect
<GrueMaster> Well, looks like it was uploaded into 20120322 image.  20120320 had 3.2.0-1409.12 kernel.
<GrueMaster> And I know it worked.
<rsalveti> yeah
<rsalveti> the difference between 09 and 10 is the "stable" fixes :-)
<GrueMaster> Pfft.  Figures.
<GrueMaster> Last time a kernel guy told me that, they fried two of their babbages.  Literally.
<GrueMaster> That was in Dublin iirc.
<rsalveti> lol
<rsalveti> true
<chris_> quit
<GrueMaster> resume
<steev> suspend
<GrueMaster> rsalveti: Do you know if someone will fix bug 943058 before 12.04 release?  This is becoming critical, as the start-r rev boards replaced earlier versions and started shipping in December.
<ubot2`> Launchpad bug 943058 in linux-linaro-lt-mx5 "Kernel doesn't support usb on newer rev quickstart boards." [High,New] https://launchpad.net/bugs/943058
<rsalveti> GrueMaster: I discussed that with the freescale landing team, and they said they would try to fix these issues in the next following days
<rsalveti> so I hope to get a better kernel before release
<GrueMaster> cool.  It would be a shame not to support the newer rev hw.
<infinity> rsalveti: What are the odds on that "better kernel" also being 3.2? :/
<rsalveti> infinity: I believe that's the goal
<rsalveti> as currently 3.2 only works for mx6
<infinity> rsalveti: If that goal is met, I'll buy you ridiculous amounts of beer at UDS (and you have no obligation whatsoever to take them back to the LT if you don't want to)
<rsalveti> infinity: hahah, that's easy ;-)
<GrueMaster> heh.  I'd add to that, but I'm not sure if I am going.
<infinity> GrueMaster: It's a short trip, drive down.
<rsalveti> well, it's a quite short travel for you
<rsalveti> yeah
<GrueMaster> Then what, sleep in NCommander's car?  Have you seen his car?
<infinity> Get a cot in Oli's room.
<infinity> He'll love that.
<GrueMaster> Darth Vader sleeping mask and all.
<infinity> But I just meant swing down for a day and say hi.
<infinity> Ideally a party day. ;)
<GrueMaster> Erm, it is an 8 hour drive, one way.
<infinity> That's short!
<GrueMaster> Not for me.  I'd have to stop and piddle every 2 hours, just to keep up with the coffee I'd need.
<GrueMaster> infinity: While you are here, care to look at https://code.launchpad.net/~gruemaster/bacula/960761/+merge/99137 and tell me if I'm doing it right?  It can wait until post beta thaw.
 * GrueMaster is learning the ropes of bug fixing where he can.
<infinity> GrueMaster: Erm, yeah.  _Description implies that there are pofiles being merged into a final template.  I assume that's not the case here? :P
<GrueMaster> I have know idea what the implication is.  In the case of the mysql package, I get a dpkg error on the one line with _Description.  On the pgsql, all lines had the error.
<GrueMaster> I haven't looked to see if there are pofiles for these, but since the error is being generated, I would say no.
<GrueMaster> At the very least, the templates should be consistent.  Either all _Description with po or not (s my patch changes).
#ubuntu-arm 2012-03-24
<slangasek> GrueMaster: templates should have _Description only if they're being postprocessed with dh_installdebconf to merge in translations from debian/po at build time
<slangasek> and if you change something to use _Description, you should also be running debconf-updatepo as part of preparing the source
<infinity> slangasek: You're reading the diff backwards, he's changing it to NOT use _Description because the maintainer originally did, but doesn't appear to have a debian/po.
<slangasek> I'm not reading a diff, I'm reading scrollback :)
<infinity> slangasek: Ahh.
<infinity> https://code.launchpad.net/~gruemaster/bacula/960761/+merge/99137
<infinity> slangasek: Looks like the templates for bacula itself are right, but some cargo-culting oops happened on the *sql plugins, and they got _Description.
<infinity> slangasek: Which, I assume, means no templates at all.
<slangasek> well, using templates without enabling translation support is not "right"
 * slangasek takes a look at the source
<infinity> Well, FSVO "right".
<infinity> slangasek: To be fair, I'm not sure what the expected behaviour would be here.  dh_installdebconf is being called.  But yeah, one set of templates uses Description, the other _Description, and no debian/po.
<slangasek> it's even using dh_installdebconf in debian/rules
<GrueMaster> slangasek: My change is exactly the opposite.  Check the mysql.template and you will see.
<infinity> slangasek: And I haven't actually looked at the output, just that Tobin claims there are no templates for *sql.
<slangasek> so the right solution here is to run 'debconf-updatepo' and *populate* debian/po
<infinity> slangasek: And to fix bacula.templates to use _?
<slangasek> yes
<GrueMaster> Fair enough.  That is something I didn't know.
<infinity> Check.
<infinity> GrueMaster: Now we know.  (And knowing is half the battle).
<slangasek> pork chop sandwiches!
<infinity> Who's a body massage MACHINE?
 * GrueMaster thinks infinity sounds like a kids commercial.
<slangasek> interesting, why does 'debconf-updatepo' fail here for me with an xgettext complaint
<slangasek> oh yes
<slangasek> you have to run 'debconf-gettextize' for the initial poing
<infinity> oh baby?
<infinity> slangasek: Okay, it seriously took me two minutes and many re-readings of "poing" before I realized it was neither a typo, nor a word I didn't know, but a verbification of "po".
<infinity> slangasek: Ouch.
<slangasek> sed -i -e's/_Description/Description/' debian/*.templates && debconf-gettextize debian/*.templates
<slangasek> infinity: you're welcome
<slangasek> GrueMaster: ^^ that's the "right" fix here
<infinity> I always have great confidence when "right" is in quotes.
<GrueMaster> Ok.  Noted.
<slangasek> although, here's a fun changelog entry
<slangasek> bacula (3.0.3-3) unstable; urgency=medium
<slangasek>   [...]
<slangasek>   * This change means that all Bacula debconf templates are finally removed.
<slangasek>     As a result, no need for translations remains.  Closing open translation
<slangasek>     bugs since there is no longer anything to translate in this package.
<slangasek>     Closes: #568469.
<slangasek>   [...]
<slangasek>  -- John Goerzen <jgoerzen@complete.org>  Mon, 08 Feb 2010 14:37:04 -0600
<infinity> *blink*
<infinity> Does it use them in postinst?
<slangasek> so why do we have debconf templates at all if Debian got rid of them in 2010 :)
<infinity> (or have a config?)
<slangasek> in Ubuntu, definitely
<infinity> How bizarre.
<GrueMaster> Well, at least I wrote bug 960761 accurately.
<ubot2`> Launchpad bug 960761 in bacula "Typo in template files for mysql & pgsql director packages" [Medium,Confirmed] https://launchpad.net/bugs/960761
<slangasek> so the *real* right solution here is to get this in some kind of sensible sync with Debian and then watch the bug factor itself out
<slangasek> and I therefore officially don't care which expedient solution you use to get it building in the meantime ;P
<jimerickson> is anyone getting any video output with todays omap4+armhf image?
#ubuntu-arm 2012-03-25
<lilstevie> I'm having an issue with the battery applet in precise, I have a dual battery system, and it is taking the secondary battery (the battery that drains first) as the primary one
<lilstevie> so when it depletes I am getting a suspend warning
<infinity> lilstevie: gnome-power-manager bug?  Ish?
<infinity> lilstevie: File away and pester seb128 until it's fixed? :P
<infinity> lilstevie: IMO, there shouldn't be a "primary" battery, it should just total up remaining/available for all batteries.
#ubuntu-arm 2013-03-18
<twb> lilstevie: hey man, you awake?
<twb> I'm thinking about getting a new arm netbook, wondering if you had any opinions.
<twb> Pretty much just want a 1kg/10"/all-day battery and running debian or ubuntu natively (chroot inside android doesn't count).  Don't care if it's sold as a tablet+dock, long as I can use it as a netbook :-)
<TheMuso> twb: If you are willing to jump through a few hoops, you can get Ubuntu running on the Samsung Chromebook.
<twb> I heard bad things about the google stuff
<twb> Something about SBK?
<TheMuso> THis is news to me...
<TheMuso> You are probably thinking of the Intel variant of the Chromebook.
<lilstevie> twb, I'm awake
<TheMuso> I think Samsung have an Arm version and an Intel version, probably named different things and look differently, but yeah.
<twb> TheMuso: not sure.  I'll see if I can find the reference I"m thinking of
<lilstevie> the samsung one does have a few issues
<TheMuso> Don't know the name differences.
<lilstevie> like melting the speakers
<lilstevie> if you futz with alsa incorrectly
<TheMuso> Ok, wasn't really aware of the issues, just know it can be done.,
<TheMuso> lilstevie: Yeah but thats fixed as of raring.,
<twb> http://mjg59.dreamwidth.org/22465.html "Don't like Secure Boot? Don't buy a Chromebook."
<twb> "Out of the box, Chromebooks are even more locked down than Windows 8 machines."
<TheMuso> twb: Yeah thats about the intel variants, I *think*
<twb> It's not clear if that's x86_64 ones
<twb> NFI how far the EFI madness has penetrated the arm space
<lilstevie> twb, remove a single gold screw and the arm chromebook is open
<twb> lilstevie: OK
<lilstevie> EFI on arm has only penetrated the windows rt devices so far
<lilstevie> arm chromebook uses u-boot
<lilstevie> RaYmAn would be better than me at this though
<lilstevie> he flashed a full devel unlocked u-boot to his device (can only be done with the gold screw undone)
<lilstevie> the gold screw basically enforces SPI writelock
<twb> OTOH the TF101 is still working fine, I'm mainly just wanting to do upgrades to its kernel and stuff that are likely to brick it for a couple of days, meaning I can't do my job.  So maybe what I *should* be doing is getting an x86 netbook instead as my backup...
<lilstevie> tf101 is dead
<lilstevie> Lo
<lilstevie> performance of chromebook is much faster
<twb> Meh, it's only doing emacs and ssh, and it's pretty much already limited by how fast I can type
<twb> >1G of ram would be nice so I can buffer more of the SD card in RAM
<twb> http://www.google.com/intl/en/chrome/devices/samsung-chromebook.html#specs says only 6Â½hr battery
<lilstevie> it says "over"
<lilstevie> :p
<twb> yeah but it's a vendor claim running vendor's OS, so when you switch to a proper linux you assume it's about 80% of their lowest claim
<Zero_Chaos> at full load I get 6 hours on my chromebook battery (like, compiling the whole time)
<Zero_Chaos> if you let it clock down it's closer to 12 hours
<twb> OK
<lilstevie> Zero_Chaos, running ubuntu
<lilstevie> or chromeos
<Zero_Chaos> lilstevie: niether ;-)
<lilstevie> Zero_Chaos, lol
<Zero_Chaos> lilstevie: gentoo
<lilstevie> figured
<lilstevie> it was either going to be debian or gentoo, but you said compiling all day
<Zero_Chaos> yeah kinda narrows it down ;-)
<twb> haha
<lilstevie> I'm unsure where the best performance is with arm
<lilstevie> gentoo for me is a little heavy when you probably need to spend a week compiling everything needed for a desktop env
<Zero_Chaos> lilstevie: closer to two days
<twb> lilstevie: surely you can cross-compile anyway
<twb> So just do it on big iron
<lilstevie> Zero_Chaos, heh thats on the a15 though right
<Zero_Chaos> then again i don't use kde so maybe a week for kde users
<lilstevie> someone said it took 16-17 hours to compile chromium on the tf201
<twb> Last time I tried to compile webkit I ran out of ram
<lilstevie> heh
<twb> Probably because -g was on
<lilstevie>  I'm running fedora on my tf201 as an experiment for the time being and it seems alright, but no EGL/GLES stuff at this stage
<twb> Oh *that's* why my old x86 netbook is in the cupboard.  It's btrfs-on-SSD shat itself
<lilstevie> lol
<twb> I worked out how to recovery /home and /srv later, but / was gooooone
<lilstevie> lol
<imblaze> hello all
<imblaze> i have a few questions about boot on android devices from uefi volumes
 * ogra_ guesses you should better ask in an android channel then
<imblaze> .
<RoyK> ,
<Tassadar> imblaze: ping
<ptl> anyone uses ubuntu in a chromebook xe303c12 here?
<angs> I am trying to install wpa_supplicant 2.0 on ubuntu-arm server but it has too much dependencies. Once someone here told a command with aptitude to install dependencies automatically, does anyone know how I can do it?
<ogra_> dependencies are always installed automatically
<infinity> angs: Are you building wpa_supplicant yourself, or getting it from a PPA, or...?
<ogra_> oh, yeah, i missed the 2.0
<infinity> angs: If it's not coming from an apt repository, apt (or aptitude) aren't going to be much help.
<infinity> angs: Though, "apt-get build-dep wpasupplicant" might give you an approximation of the things you need to built it, if that's what you were looking for.
<infinity> s/built/build/
<angs> yes I am trying to build it myself
<angs> than you it install some packages now
#ubuntu-arm 2013-03-19
<user__> hi
<user__> anyone here good with arm stuff
<user__> hello?
<Tm_T> user__: that is rather vague question, try ask what you actually do need instead?
<user__> hi anyone able to give me a hand with a small issue im having i got AOKP installed and am trying to install backtrack. im getting an error message saying cant find bin/bash
<user__> im sure its something simple
<user__> ?
<ppisati> ogra_: so, what was the outcome of the "omap4 desktop image" situation? i remember a last week talk in #distro, when people told you we could drop it and you said you were going to send an email
<ppisati> ogra_: isn't it?
<ogra_> still waiting for the final word
<ogra_> there was some discussion if we should just keep them as is with no support at all ... or if we should look into making them ubuntu touch images
<ppisati> ogra_: with no pvr you mean, right?
<wgpenney> Anybody have experience in setting up a sound card for nvidia-tegra3, seems to be missing the tegra codex
<wgpenney> currently running xubuntu 12.10
<ogra_> works fine on the nexus7 images
<ogra_> out of the box
<wgpenney> pavcontrol is not showing a sound card configured on my TF300T
<ogra_> so check on the alsa level make sure that works fine etc etc
<wgpenney> what's the command? how do I check the level?
<XorA> from memory on the transformer the HDMI is the first sound card
<XorA> and the analouge the second
<XorA> which is reverse from most PCs and confuses people
<XorA> aplay -l to list all soundcards
<wgpenney> Thanks, aplay -l hangs after displaying card 0: Tegra [HDA NVIDIA Tegra], device 3: HDMI 0
<XorA> wgpenney: I bet your kernel has oopsed
<wgpenney> is there a log for the kernel oops? or is this only available when debugging the kernel.
<darkfader> i think oopses can't be logged in most cases
<darkfader> you can try using netconsole, but even that might not see them
<wgpenney> Thanks for your help guys, I relay this back to the kernel developer.
<lithiumjake> does anyone know if there is a version to tcl/tk 8.6 compiled for ubuntu/arm?
<ogra_> lithiumjake, all ubuntu packages are built for arm
<hrw> ogra_: 'all'
<hrw> ogra_: chromium-browser went >22?
<ogra_> hrw, well, all that arent actually x86 specific ... like syslinux
<ogra_> nope, but there is a chromium-browser binary package
<ogra_> i didnt say they are all recent ;)
<hrw> ;)
<XorA> hehe
<ogra_> but in natty the FTBFS list was actually zero
<ogra_> which means all package have an arm equivalent in the archive
<ogra_> not necessarily matching the current source though
<infinity> ogra_: The FTBFS list in natty wasn't zero...
<ogra_> well, then it was lucid
<ogra_> we had it at zero in one release
<infinity> It's never been zero, AFAIK.  The outdates list is pared down to zero when people pay attention (which Colin and I started doing for oneiric, and hadn't been done previously for years...)
<infinity> s/oneiric/precise/ possibly.  Can't remember which sprint we noticed the world was crufty.
<ogra_> i know for sure it was zero at some point
<ogra_> with quite some effort from doko in the last days before release
<ogra_> lucid, maverick or natty ... i cant remember which
<infinity> That would be actually impossible.
<infinity> That's all I'm saying. :P
<infinity> There have always been packages in the archive that are arch:any but FTBFS on some arches.
<ogra_> http://qa.ubuntuwire.org/ftbfs/ was empty i should say
<infinity> And given that I only knocked out some of those from ARM after I came back to the company, they clearly didn't build before that.
<ogra_> not sure if that covers 100%
<ogra_> but i always thought it did
<ogra_> we massively celebrated that in the arm team
<ogra_> thats why i remember it so well
<infinity> Hrm.  Well, then, possibly some things built but built incorrectly. :P
<ogra_> thats entirely possible
<infinity> Like, anything that needed get/setcontext before glibc 2.15 happened.
<infinity> But those should have been FTBFS.
<ogra_> it was the release where NCommander made fpc build the last minute too
<ogra_> (and i think nobody ever tested if it worked )
<ogra_> i'm pretty sure he didnt :)
<infinity> I'm still dubious of the FTBFS empty claim, given that I know a non-trivial chunk of the archive just plain couldn't build on ARM.
<infinity> Unless doko went and artificially arch-restricted a bunch of packages. :/
<infinity> Which would not only be "cheating", but wrong.
<ogra_> i dont think he did thatm no
<infinity> And I find myself wondering now if there may still be a bunch that need to be undone.
<ogra_> i always worked along the above website
<ogra_> and i know we always had a few packages on there until that one specific release
 * ogra_ twiddles thumbs ... watching a repo sync of a 7G repo fight with the meta ./update script 
<ogra_> i really wouldnt mind fiddling with android stuff ... IF THE SROURCE TREES WOULDNT ALWAYS PULL GIGS OF USELESS STUFF !
<ogra_> sight
<XorA> Google makes money from network traffic :-)
<ogra_> heh
<ogra_> i should check if there are little ads between the normal network packages, eh ? :)
<XorA> that progress counter probably has sumbliminal ones
<ogra_> heh
<lithiumjake> see, that's why the tcl community rocks so hard, someone built a tcl 8.6 tclkit for arm just for kicks :)
<infinity> ?
<lithiumjake> i had asked earlier if anyone built tcl 8.6 for ubuntu-arm (ppa or whatever).
<infinity> I take it this isn't free software that ships in Debian/Ubuntu, which would mean it built on all arches? :P
<infinity> tcl8.6 is in the archive.
<ogra_> as i said above :)
<infinity> apt-get install tcl8.6
<infinity> Oddly enough.
<XorA> thats just not 1337 enough obviously ;-)
<infinity> https://launchpad.net/ubuntu/+source/tcl8.6/8.6.0-1
<lithiumjake> i'm running 12.04 in chrooted environment on a chromebook
<lithiumjake> but be snide, that's cool
<infinity> It might have helped if you specified that?
<lithiumjake> E: Unable to locate package tcl8.6
<infinity> But the tcl8.6 source package probably compiles without modification on precise.
<ogra_> lithiumjake, universe is enabled ?
<infinity> ogra_: It's not in precise.
<ogra_> oh
<infinity> ogra_: tcl8.6 is brand new.
<ogra_> ah right, i only checked on my chromebook
<XorA> apt-get install -t raring tcl8.6
<lithiumjake> perhaps when my linux-foo is better, I help with things like this
<ogra_> that has never seen anything else but raring :)
<infinity> Still, the question was "does anyone know if there is a version to tcl/tk 8.6 compiled for ubuntu/arm", which was pretty non-specific about versions. :P
<ogra_> yeah
<lithiumjake> XorA, would that command be safe to try to install 8.6 on 12.04?
<infinity> XorA: That assumes raring enabled in his sources.list, which is probably not what he wants.
<lithiumjake> oic
<infinity> XorA: Not without some healthy pinning (or just upgrading wholesale)
<XorA> lithiumjake: without pinning that would be a very dangerous command
<lithiumjake> okay, thanks
<XorA> raring seems pretty stable on chromebook
<ogra_> yeah
<infinity> Well, he's running in a chroot anyway, raring may be the better option as a development platform.
<ogra_> and faster ...
<XorA> I never actually tried 12.04, I just used it as a stepping stone to raring
<infinity> I still run 12.04 on all my headless/server machines.  And will until 14.04 or later, I'm sure.
<infinity> But raring's been very friendly on my laptops.
<infinity> Can't complain.
<ogra_> yup
<ogra_> well, unity and mali dont get along so nicely here
<XorA> dont have mali working here so couldnt comment
<ogra_> funnily the ubity support test screams "DOIT" in your face with big green letters if you run it :)
<ogra_> *unity
<ogra_> but it leaves me with an empty desktop ... and i was to lazy to find out why this time
<ogra_> all other GLES/EGL and composite stuff just works fine thougt
<XorA> working video accelleration would be nice, but I can wait
<infinity> I don't have a Chromebook, so can't comment.  I'm not one of the cool kids.
<infinity> (Or, more realistically, I like my laptop(s) and don't need yet another)
<XorA> I copied *GL* and *mali* from chrome /usr/lib but obviously still missing something
<ogra_> you need to hack up the mesa stuff to not take precedence
<XorA> but if it requires armsoc that makes chromebook unusable for me
<ogra_>  /etc/ld.so.conf.d ...
<ogra_> intresting, for me it works rock solid as long as i dont switch VTs
<XorA> you need to switch VT to suspend
<ogra_> which i dont do anyway
<ogra_> ah ... i never suspend either :)
<ogra_> havent travelled with my CB yet
<XorA> works fine with fbdev, so you can switch for travel
<ogra_> and even then ... starup time is around 10sec or so
<ogra_> so i can as well shut down
<XorA> yeah boot is lightning fast
<ogra_> what i'd really like would be a more recent chromium though
<ogra_> FF is unusable on arm ...
<qengho> :(   It might not be long to get a one-off.  I think the build-bots are going to have trouble.
<ogra_> (it wasnt a few releases ago, i always wonder what happened)
<XorA> heh I used to run firefox on my Collie SL-5500
<ogra_> i used to use FF with fbdev on my ac100
<ogra_> back then it was fine
<ogra_> but the last two releases at least the rendering backme unbearably slow
<ogra_> stuttering when scrolling etc
<XorA> ogra_: odd, seems to be usable here on chromebook
<ogra_> did you compare to chromium ?
<ogra_> and did you try it on something like G+
<XorA> tried on facebook
<XorA> which is about as bad as it gets
<ogra_> seems as soon as some javascript is involved it crawls for me
<XorA> although I do have adverts disabled
<ogra_> well chromium uses mali extensively
<ogra_> and supports flash ... so i dont care about ads
<XorA> chromium certainly faster
<XorA> and I guess a far test as its non mali vs non mali
<ogra_> yeah chromium + mali just flies
<XorA> oddly enough not in ChromeOS :-(
<ogra_> heh, yeah
<user__> anyone able to give me a hand putting ubuntu on android
<Aceface> anyone able to give me a hand putting ubuntu on android
<kulve> Aceface: more specific questions may lead to better answers
<Aceface>  trying to install ubuntu on android  -  http://pastebin.com/WH1NE7fG. : error
<Aceface> http://pastebin.com/JXRZjy5r  ; script
<Aceface> anyone able to give me a hand putting ubuntu on android
<Aceface> droid razr  rom: AOKP and kernal: 3.0.8-g29cf5e7 /hudsoncm@il93xdroid54 #1
<Aceface> any ideas, im not good with scripts, im sure its something simple
<k1l_> is it backtrack? or ubuntu? and is it a ARM razr or is it the intel razr i?
<Aceface> BT arm
<k1l_> Aceface: better ask the one you got that script from
<Aceface> got it from backtrack site
<ogra_> so why dont you ask in their channel then ?
<ogra_> here hardly anyone knows something about backtrack
<Aceface> well bt is samething as ubuntu
<Aceface> its is ubuntu
<Aceface> people in BT channel are fags lol
<k1l_> Aceface: if its ubuntu why its not named ubuntu? :)  ask their support. noone here knows what they changed.
<Aceface> mkay thx anyways
<sbaugh> >people in BT channel are fags lol
<ogra_> sbaugh, watch your language please
<sbaugh> ogra_: I was just quoting
<ogra_> oh
<ogra_> sorry, i missed it above
<ogra_> so that was to Aceface then
<ogra_> sbaugh, thanks :)
#ubuntu-arm 2013-03-20
<rsalveti> infinity: hey, just noticed that even after upgrating to the latest usb-creator-gtk, the upstart init file was still available at my system
<rsalveti> https://launchpadlibrarian.net/130683892/usb-creator_0.2.46_0.2.46.1.diff.gz
<rsalveti> had to purge & reinstall to make the file go away, guess because it's part of /etc the update didn't remove it by default
<rsalveti> the annoying ubuntu core installer was showing here even when inserting a usb mouse :-)
<infinity> rsalveti: xnox was supposed to have fixed that with an rm_conffile. :/
<infinity> rsalveti: I guess he never uploaded after we discussed it.  Bah.
<xnox> infinity: and it's nice to know that dh_* got support to do this now. http://manpages.debian.net/cgi-bin/man.cgi?sektion=1&query=dh_installdeb&apropos=0&manpath=sid&locale=en
<xnox> infinity: uploaded.
<mjrosenb> morning all.
<angs> I have ubuntu-server prebuild image for a beagleboard (omap3). where is the .config file located?
<ogra_> angs, in /boot usually
<angs> thank you ogra_
<lilstevie> ogra_, I've been watching that convo for about the last half hour, I feel like stabbing myself in the eye :/
<lilstevie> ogra_, this is what canonical gets for using android as a base though :p
<ogra_> hehe
<ogra_> patience is golden
<ogra_> yeah
<lilstevie> haha
<lilstevie> patience wears thin when you have that on a daily basis
<ogra_> do a month of support in #ubuntu and you will get along with such chaps
<ogra_> its all about training
<lilstevie> I'm in #ubuntu, but I mostly ignore it
<ogra_> (and the right tranquilizers)
<lilstevie> haha
<lilstevie> sounds about right
<sim590> Has anyone any news on the 3.1.10 Linux kernel for Ubuntu? Is the keyboard mapping right? Graphical driver working?
<ogra_> ?
<ogra_> can you elaborate
<sim590> I'm speaking about the Jintha kernel https://github.com/Jhinta/TF101-GNU-kernel/commits/TF101
<sim590> I once tried it and the keyboard keys were messed up. I couldn't use CTRL+C by default
<ogra_> we dont really have any tf101 images ... probably lilstevie knows more, i think he did a community port
<sim590> what's a community port?
<ogra_> something thats not supported and possibly uses packages that arent in the ubuntu archive
<sim590> okk
<sim590> thanks for your time and answers
<ogra_> but as i said i think lilstevie knows more
<ogra_> he is the transformer guy around here
<lilstevie> I no longer support the tf101 due to horrible support for tegra2 by nvidia
<lilstevie> I keep meaning "one last update" but I lose motivation every time I try booting
<ogra_> yeah. you are missing a marvin24 :)
<lilstevie> heh :p
<ogra_> who does awesome work on the tegra2 kernels for ac100
<lilstevie> I've been a little more focused on getting the perfect setup for the tf201
<sim590> You were having problem with 2.6.36.4 kernel too?
<angs> I am trying to install a package  on ubuntu-server but I  get "No space left on device" error, and df shows that /dev/mmcblk0p2 is used 100% .  what directories would be fine to delete?
<ogra_> sudo apt-get clean
<ogra_> try that first
<angs> I did apt-get clean and autoremove but the package that I am installing  https://github.com/cozybit/distro11s executes apt-get update by itself
<angs> what would be best to free space? remove packages?
<angs> or remove directories?
<ogra_> yes
<ogra_> you can indeed remove /usr/share/doc ... but check with du -hcs  /usr/share/doc/* first if its worth it
<ogra_> (and indeed, you shouldnt distribute that image since that contains all copyrights)
<angs> 16 MB
<ogra_> well, thats something
<angs> apt-get autoremove and clean frees around 200 MB
<ogra_> also if you have any deb-src lines in your sources.list, drop them
<Snark> check /var/cache/apt/archives !
<ogra_> then wipe /var/lib/apt/lists/ and run sudo apt-get update
<ogra_> that should give you another few MB
<ogra_> Snark, thats what apt-get clean wipes
<angs> thank you
<angs> is it possible to list the installed packages according to the space that they occupy?
<Snark> ogra_, oh? I thought it removed only outdated packages :-/
<ogra_> grep-dctrl ... very powerful but also very complex
<ogra_> Snark, thats autoremove :)
<ogra_> clean wipes the cache
<Snark> ok
<ogra_> autoremove removes packages that have nothing depending on them
<doomlord> anyone here got dual boot android/linux working on an n7?
<doomlord> i just got an n7 and would be curious to have that setup..
<jakayeee> ANY SWEET LADY WANT LONG TERM RELATIONSHIP PM ME
<bla> Hello.
<ppisati> lool: ping
<lool> ppisati: pomg
<ppisati> lool: it's ok loo, i sent an email earlier
<ppisati> lool: about flash-kernel
<ppisati> lool: fell free to chime in
<ppisati> *feel
 * ppisati -> halt -p
#ubuntu-arm 2013-03-21
<brute-force> Hi everyone, i'm having an issue with an ubuntu app, may attach a screenshot of my issue?
<ppisati> ogra_: FWIW, i sent the rename patch, if you can't work on flash-kernel i can give it a look
<ppisati> ogra_: and here is a kernel with the new name
<ppisati> ogra_: http://people.canonical.com/~ppisati/linux-image-3.8.0-13-multiarm_3.8.0-13.24~musb3_armhf.deb
<ppisati> ogra_: omap3/4, imx6 and vexpress
<ogra_> ppisati, right, the DBB structure needs some changes for this
<ogra_> *DB
<ogra_> yuo didnt by chance talk to debian about it ?
<ppisati> ogra_: nope
<ogra_> so that we dont have to carry our own patch for an incompatibel naming scheme ?
<ogra_> hmm, k
<ogra_> they are just implementing the same but still discuss the naming afaik
<ogra_> would really have been good to coordinate on that
<ogra_> since the f-k changes wont be small
<ogra_> (thires neither ... but we will have to rip out their naming and replace it with ours on eery merge now)
<ppisati> ogra_: i didn't look at the code, but isn't an s/omap/multiarm/ change?
<ogra_> no, since you can use both
<ogra_> theh DB needs an additional field that tells f-k that you can do that and the code needs to manage both types
<ogra_> else upgrades wont work and third party vendor kernels wouldnt either
<ogra_> (and especially for omap there is an endless amount of BSP and vendor kernels)
<ppisati> ogra_: i really don't get it
<ppisati> ogra_: i mean, we imported the new debian flash-kernel
<ppisati> ogra_: that changed our habits and made impossible to install previous kernel
<ogra_> yes, to minimize the delta with debian
<ogra_> which is a bug
<ogra_> you can blame me for not having gotten to it yet
<ppisati> ogra_: no no
<ogra_> yes, you can :)
<ppisati> ogra_: it's just, we can't wait for debian for evrything
<ogra_> i promised it ages ago and forgot about it
<ogra_> we dont
<ogra_> we usually patch stuff proactively ... but patches need to be able to flow back somehow, else we need to maintain the delsta
<ppisati> ogra_: anyhow, if you can work on that ok
<ogra_> i plan to ... today actually
<ppisati> ogra_: else, i'll tackle it
<ppisati> ogra_: don't want to step on your feet
<ogra_> but it would have been good to coordinate the naming with debian in advance
<ogra_> so we dont have to carry a huge patch that renames the world
<ogra_> i think they are aiming for something like armmp
<ogra_> lool, any comment ^^
<marvin24> unfortunately, tegra will only support multiarch in 3.10 or so
 * lool reads up
<lool> ogra_: topic is installing old kernels or multiarm kernels?
<ogra_> multiarm
<ogra_> for older i'll just add a --force-version that overrides the check
<ogra_> thats trivial
<ogra_> for multiarm we'll need a new DB field and code rthat uses it i think
<ogra_> MultiPlatformCapable=true ... or some such
<ogra_> and then match against that in the code to allow -multiarm vs -$flavour if its available on disk
<ogra_> lool, what bothers me is that we dont use a consitent naming with debian that would save us a delta
<ogra_> marvin24, well, 3.10 isnt far :)
<lool> ogra_: if it helps, we can split the dbs and change the rules with dpkg-vendor to have Debian and Ubuntu dbs
<ogra_> we'll see, let me come up with some code
<lool> ogra_: for multiarch, I'm not quite sure a new field is the way to go; you could just list multiarch as the kernel flavor for all hardware supported by this kernel
<ogra_> k
<lool> basically just listing multiarch in Kernel-Flavors might just work
<ogra_> k
<lool> s/multiarch/multiarm/g sorry
<lool> these words are too close in my brain  :-)
<ogra_> yup
<lool> multiarm should be sheeva or something
<ogra_> heh
<ogra_> lool, ppisati, http://paste.ubuntu.com/5634079/
<ogra_> for a quick way to skip the version check
<ogra_> lool, so regarding your mail you seem to suggest to enforce -multiarm only i.e. so -omap kernels wouldnt work at all anymore ... i dont think i like that idea it makes using a BSP or vendor kernel thats not from mainline impossible ... i'd rather see us supporting both, the old flavour name and multiarm here ...
<lool> ogra_: So the flash-kernel $version is just for backwards compat
<lool> ogra_: But you could implement force-version in a simpler way now, keeping this compat aroun
<ogra_> simpler than above ?
<lool> ogra_: You would add a block just like for --machine, then skip the latest_version check if force_version is set; if force_version is set, just set kvers to it
 * ogra_ found that fairly simple :)
<lool> ogra_: Welll, simpler as in more readable
<lool> it would be more lines
<ogra_> yeah i did that first, but it adds extra vars and stuff
<lool> that's fine
<ogra_> k
<ogra_> so about the other stuff
<ogra_> a) we never remove kernels anywhere
<ogra_> and i wouldnt see flash-kernel as a responsible tool to do that if we would
<ogra_> b) we should go on supporting the old naming scheme for people rolling their own kernels
<lool> a) -- yup, I think that's entirely orthogonal though
<ogra_> c) i definitely think the packaging conflict/breaks/replaces stuff has to happen in the kernel package if needed
<lool> c) -- yup
<ogra_> and i would actually expect ppisati to already have all that stuff in the new packaging
<lool> b) -- this should just keep working as it does now, unless they were using the same kernel flavor that we intend to drop
<lool> there is actually another way to implement this which is completely different
<lool> OMG I'm not sure I ought to mention this
<lool> ogra_: Another entirely different pas is superseding Kernel-Flavors with Kernel-Configs
<lool> this is quite different
<ogra_> well, i would really just add a "MultiarmCapable" field to the DB
<lool> uh
<ogra_> and extend the flavour check a bit ... in a way that -multiarm is preferred if existing
<ogra_> that way you can still support both
<lool> I dont think that relates to the db, or then it's another d
<lool> d
<lool> db
<ogra_> but need to make sure -multiarm is removed when you use your own play around kernel
<lool> I'm all confused now
<lool> the requirements in email seemed relatively clear to me: switch from -omap and others to -multiarm
<lool> I think the plan is fair enough there
<lool> Now I'm not quite sure what requirement we're discussing
<ogra_> i want to keep the ability of being able to use -omap
<ogra_> you seem to want that  "Kernel-Flavors: multiarm" replaces "Kernel-Flavors: omap"
<ogra_> i would like to keep Kernel-Flavors: as is and add a new field that tells us "this machine can also use multiarm"
<ogra_> so people rolling their own 3.2 kernel which cant be multiarm can still use -omap
<ogra_> (as an example)
<lool> ogra_: we could have some kind of priority in the database to support multiple cases, but it kind of strikes me as dangerous
<lool> I'd rather folks add a local db of their own somewhere and have to maintain it
<ogra_> why, -multiarm would always be preferred
<lool> or we define how custom kernels are named (e.g. -custom) and that's it
<lool> ogra_: I dont get it, do you want them to use -omap or -multiarm
<ogra_> if there is no -multiarm binary in /boot we just fall back to "Kernel-Flavors:
<lool> in the end we support this and that hardware, this is the kernel you're supposed to use, and that's it
<ogra_> i want us to use -multiarm (which doesnt need a "Kernel-Flavors:" field at all anymore)
<ogra_> and still levae the opportunity to people building from older or BSP branches to have -omap
<ogra_> or -omap4
<ogra_> or -armadaxp
<ogra_> lool, oh, and looking at your mail ... "we have some dependencies in place which ensure that flash-kernel  requiring multiarm is installed immediately after -omap is replaced by  -multiarm (not before, not any later)" ... that cant work, nothing depends on flash-kernel anywhere
<ogra_> iirc on your request back then
 * ogra_ sighs ... that whole discussion shoudl have taken place several months ago ... and debian should have been heavily involved
<ogra_> hmm, so for the transition and wrt depends, i guess ppisati could add a versioned dep on f-k to his transitional package, that will go away at some later point anyway
<ogra_> through clever conflicts/breaks/replaces login
<ogra_> *logic
<ogra_> hmm, so lets see if that works at all ...
<ogra_> ppisati, can you test with editing the db and just change the "Kernel-Flavors:" field in your omap entry ?
<ogra_> theoretically that should just make it work
<ogra_> (practically i fear that 1.2.3-omap is simply bigger than 1.2.3-multiarm ... which triggets the kver issue)
<ppisati> flag@flag-desktop:/usr/share/flash-kernel$ grep Kernel-Flavors db/all.db  | grep omap
<ppisati> flag@flag-desktop:/usr/share/flash-kernel$
<ogra_> err
<ppisati> flash-kernel 3.0~rc.4ubuntu29
<ogra_> yeah i have the source here
 * ogra_ is baffled 
<ogra_> there is actually no "Kernel-Flavors:" in the DB
<ogra_> so mind adding it for a test ?
<ppisati> ogra_: there's actually
<ppisati> ogra_: but there's no Kernel-Flavors in it
<ogra_> for omap/omap4 ?
<ppisati> yes
<ppisati> Machine: OMAP3 Beagle Board
<ppisati> etcetc
<ppisati> and below omap4
<ogra_> doesnt have a Kernel-Flavors: line here
<lool> ogra_: Of course it can work, you Break flash-kernel << version-that-works
<ogra_> lool, from what ?
<ogra_> lool, nothing depends on f-k
<lool> from the kernel package
<lool> this wouldn't be a Depends but a Breaks
<ogra_> yeah thats what i mean, but from the transitional package
<ogra_> which will vanish anyway at some point
<lool> Either from the new binary packages or from the meta pulling the right stuff
<ogra_> why not from the transitional one ?
<ogra_> ppisati, so whats in the Kernel-Flavors: line you see there for omap/omap4 ?
<lool> I don't know which one you mean
<lool> anyway, from some kernel package that ultimately tries to pull -multiarm
<ogra_>  "we have some dependencies in place which ensure that flash-kernel  requiring multiarm is installed immediately after -omap is replaced by  -multiarm (not before, not any later)"
<ogra_> from your mail
<ppisati> ogra_: no no, there's no Kernel-Flavors in those omap3/4 entries
<ogra_> "we have some transitional package which pulls in -multiarm when you  had e.g. -omap installed"
<ppisati> ogra_: ok, i got it
<ogra_> ppisati, ah
<ppisati> ogra_: i'll add an entry
<ogra_> ppisati, so please add one with multiarm
<ogra_> then try again, that should make it not fall over in the kver check
<ogra_> though looking at the code the version check runs before the flavour check
<ogra_> me guesses that needs to move up
<ppisati> ogra_: ok
<ppisati> ogra_: i guess '3.8.0-13-multiarm' is lexically inferior to '3.8.0-10-omap'
<ppisati> ogra_: that's why it fails
<ppisati> ogra_: that's the only reason why it fails
<ppisati> ogra_: let me do some more testing
<ogra_> well, i still dont get how it gets its flavour at all
<ppisati> ogra_: i don't know, it works, don't touch it
<ppisati> ogra_: ah, and it works on imx6 too!
<ogra_> yeah, it worked in the past by a matter of luck and cosmic rays :)
 * ppisati loves cosmic rays
<ogra_> hehe
<ppisati> let me build an abi bumper kernel
<ppisati> *bumped
<ogra_> that wont make m larger than o
<ppisati> ogra_: 3.8.0-13-omap vs 3.8.0-14-multiarm?
<ogra_> the check logic is pretty screwed up due to the ordering
<ogra_> the flavour check actually uses the version ... so the version check comes first all the time
<ogra_> hmm, abi bump might work, not sure
<ogra_> just cp the binary around ;)
<ppisati> that's what i'm doing
<ogra_> no need to build
<ppisati> :)
<ppisati> watch out:
<ppisati> flag@flag-desktop:~$ sudo flash-kernel
<ppisati> flash-kernel: installing version 3.8.0-14-multiarm
<ppisati> Generating kernel u-boot image... done.
<ppisati> Taking backup of uImage.
<ppisati> Installing new uImage.
<ppisati> Generating initramfs u-boot image... done.
<ogra_> haha
<ppisati> Taking backup of uInitrd.
<ppisati> Installing new uInitrd.
<ppisati> Taking backup of preEnv.txt.
<doomlord> Does ubuntu-arm have a 'virtual mouse' when running on a tablet ( i know its not as good as dedicated touch ui)
<ppisati> Installing new preEnv.txt.
<ppisati> Taking backup of uEnv.txt.
<ppisati> Installing new uEnv.txt.
<ppisati> ABI bump FOR THE WIN! :)
<ogra_> heh, yeah
<ogra_> though i'm still confused about the missing flavour entry in the db
<ogra_> but at least it saves us also from having that dependency stuff
<ppisati> so, nothing else userspace wise?
<ppisati> ogra_: ^
<ppisati> lool: ^
<ogra_> well, i'll add your --force-version now :)
<ogra_> but nothing for you to do apart from making sure your version is high enough
<ogra_> and indeed the proper debian/control entires to replace -omap stuff and do a clean transition as lool described in his mail
<ogra_> (in your kernel package)
<ppisati> ogra_: i think i did all the stuff in debian/control
 * ppisati goes to re-read the email
<ogra_> iirc breaks/replaces/provides
<ogra_> for the former versions of the kernels ... (omap, armadaxp ? ... do we have omap4 in there yet ? )
<ppisati> * we have some transitional package which pulls in -multiarm when you had e.g. -omap installed
<ogra_> yeah
<ppisati> isn't enough to point meta to the new -multiarm kernel?
<ogra_> well you want to replace meta too ...
<ogra_> currently linux-omap is installed
<ppisati> ogra_: right
<ogra_> and you want that to become linux or linux-multiarm
<ogra_> so if i dist upgrade there must be an empty package called linux-omap that makes sure the new nly named one is pulled in
<ppisati> right
<ogra_> so either linux-omap vanishes from the archive and your new meta provides linux-omap (and all other flavours it replaces) or you have a transitional package
<ogra_> else apt wont upgrade your kernel ...
<ppisati> ogra_: ok, i'll let someone with more debian packaging knowledge than me handle that
<ogra_> ok
<ogra_> the abi bump happens anyway if i understood right ?
<ppisati> ogra_: i'll ask to bump
<ppisati> ogra_: but yes
<ogra_> great, i'll add the --force for you :)
<ogra_> so we can finally close that old bug
<ogra_> ppisati, https://www.svtronics.com/index.php?route=product/product&product_id=33 ... the artist formerly known as "panda"
<infinity> ppisati: Dude, "multiarm"?  What?
<ppisati> ogra_: it's real! :) can't believe it! :)
<ppisati> infinity: arm multiplatform
<infinity> ppisati: I know what it means, I was asking who decided on that ridiculous name for the flavour?
<ppisati> infinity: me, thanks
<infinity> ppisati: We all agreed to have a -generic kernel ages ago.
<ppisati> infinity: did we?
<infinity> We did.  Was in several kernel team specs.
<infinity> Well, generic and generic-pae (or generic-nonpae and generic, we hadn't stopped bikeshedding)
<infinity> Since LPAE on A15 needs a -pae kernel.
<ppisati> infinity: we can call it generic
<ppisati> infinity: i don't have any atatchment to the flavour name
<infinity> Kay.  Sorry for the strong reaction. :P
<infinity> But yeah, we should just have generic and be done with it.
<infinity> ppisati: As for the meta business, we'll do transitional metas.  Just hard rename omap to generic, don't try any silly provides.
<infinity> ppisati: We have precedence for this with server->generic and generic-pae->generic, etc.
<ogra_> as long as do-release-upgrade works ...
<ogra_> which shurely all of our arm users use all the time :)
<infinity> ogra_: It'll work fine, like I said, it'll be the same migration path as x86 kernels in the past.
<ogra_> k
<ogra_> bah, who always uploads these chromium ftbs to the ppa
<infinity> ogra_: As for "does -generic support omap4", the answer is "yes", but we won't swap the metas around to force that upgrade, since we want PVR to keep working for people.
<infinity> So, omap4/raring will still use the quantal 3.5.0 kernel.
<ogra_> well... i wouldnt mind -generic on server
<ogra_> but that gets to complex
<ogra_> i suppose
<infinity> Not worth the effort, really.
<ogra_> yeah
<infinity> And not guaranteed to be an upgrade. :P
<ogra_> heh
<infinity> Anyhow, the 3.5.0 Q kernel will be supported longer than R is, so this all magically works out.
<ogra_> will be ?
<ogra_> won't be you mean
<infinity> Yay for reduced lifecycles having serendipitous side effects.
<infinity> Will be.
<infinity> Q is 18mo, R is 9.
<qengho> ogra_: which ppa?
<ogra_> oh, right
<ogra_> qengho, canonical-arm-dev :) i'm not moaning about the ppa ... i'm moaning about it failing :P
<qengho> ogra_: Ah, right.  Speaking of, can you add me to that team?
<qengho> ~cmiller
<ogra_> there should be a rule that every 100 uploads one will magically build :)
<qengho> Well, if we're just legislating reality to our liking, I vote every one builds, without bugs.
<ogra_> qengho, done
<qengho> Thx.
<suihkulokki> ogra_: better late than never, if you can mail debian-arm a summary of how you are going multiplatform, it would be nice
<ogra_> suihkulokki, yep, planning to
<infinity> ogra_: Where is this mail thread?
<infinity> ogra_: Almost everything I'm seeing in backscroll is wrong.
<ogra_> debian-arm
<infinity> ogra_: There's no need for breaks/replaces/provides, or any of that.
<ogra_> o which one do you mean
<infinity> ogra_: I mean the one you refer to involving you, Loic, and Paolo?
<ogra_> well, its all moot anyway
<ogra_> so just ignore
<infinity> It is? :P
<ogra_> the whole discussion was based on the assumption that we have the flavour in the DB ... which we dont ... the issue was a simple versioning mistmatch
<ogra_> which the abi bump fixes
<infinity> Right.
<infinity> Just hoping no one took the rest to heart.
<ogra_> but i guess ppisati wouldnt mind if you give him a hand with the debian/control changes
<infinity> ppisati: The only debian/control* changes required are s/omap/generic/ and you're done. :)
<wookey> hmm /me never notices debian-arm anymore as it still goes to my aleph1 address which ends up on different box due to mail server mysteries
<infinity> ppisati: (Assuming an ABI bump to cover package conflicts)
<ppisati> infinity: yep
<wookey> but I am interested in single zimage kernel packaging as it looks like I'll be miugged into making it work for linaro stuff
<infinity> I think I already promised that I'd fix d-i for it in both Debian and Ubuntu.
<ogra_> well, debian seemingly will call it armmp
<infinity> I must have been drinking at the time.
<wookey> better go and read thread I suppose. who is ppisati
<ogra_> you will likelly endu up with linux-arm64-armmp over there at some point :)
<infinity> ogra_: arm64 shouldn't need such a designation, it should be MP from the start.
<ogra_> wookey, ppisati is an italian who missed the pope election and thus still works for us in the kernel team on our arm kernels
<infinity> ogra_: But yes, it would make more sense if Debian went with what they do on other arches and just called it, say, -armv7 or -arm32 or something.
<infinity> wookey: You may have more influence over silly naming in Debian than I would, if you have a better option than armmp. :P
<ppisati> ogra_: next time that role will be mine... i swear...
<infinity> Debian kernel flavours are a mess anyway.
<ppisati> "Scream for me Vaticaaaaaaannnn!!!!"
<ogra_> haha
<wookey> hmm. you're right, he does seem quite italian :-)
<infinity> -686, -amd64, -alpha-generic, there's no consistency.
<wookey> consistency, schmistency
<infinity> Anyhow, I don't really give a crap what Debian names it, I just need to know for the d-i commits.
 * wookey knows nothing of kernels. Whatever looks good to an unfortunate punter picking from a list is probably good
<infinity> Since it won't have the same name as Ubuntu's similar flavour.
<wookey> we could try and have the same name if there no good reason not to
<infinity> wookey: The good reason is consistency. :P
<infinity> wookey: We have -generic on i386 and amd64 already.
<wookey> I thought there was a plan to make the kernel packaging less gratuitously differrent
<infinity> wookey: Something gratuitously different on ARM is silly.
<infinity> wookey: The kernel packaging ain't converging any time soon.  There may be some thought sharing or even some cherry-picking, eventually, but they're not going to converge.
<infinity> (Not unless Debian adopts our naming scheme, cause we're sure not adopting theirs)
<infinity> That statement needs a "nyah nyah" on the end of it, but you get the idea.
<wookey> the naming and the packaging are probably fairly independent
<infinity> True.
<infinity> I know our kernel team just ate a DD who's going through debian* and picking it apart.
<infinity> But I don't think the goal was convergence.  Just tidying.
<wookey> separating the tools seems like a good thing to copy from debian for example
<wookey> it would remove half the build-deps
<infinity> Honestly, with our kernels being so wildly different in many ways, I'm not sure convergence matters.
<wookey> except for people like me who have to hack both
<infinity> Breaking out tools would be good, and it's our radar already.
<infinity> s/our/on our/
<infinity> Realistically, you shouldn't have to touch both much more than you already have.
<ppisati> ok, bt there's already a debian.master/control.d/vars.generic
<infinity> And it's pointlessly x86-specific.  Fail.
<infinity> (It's also wrong)
<wookey> there cross fixes, tools fixes, bootstrap fixes, multiarch fixes so far and they are mostly not transferrable due to radically different packaging, which is annoying.
<infinity> wookey: Sure, but you've done those fixes, convergence now doesn't get you anything.
<wookey> next there will probably be a pile of single zimage fixes
<wookey> they aren;t all upstream yet so not really 'done'
<wookey> you just like arguing
<infinity> Well, yes.  But in this case, convergence is really, really hard.
 * wookey goes to fix kernel build.
<infinity> So, you're asking people to do a ton of work that they don't actually have to. :P
<ogra_> wookey, nahh, he doesnt, hs is a https://lh6.googleusercontent.com/-RGqGhbZCxmI/UUraE5SMbGI/AAAAAAAABWE/IRwgZvae-5c/s707/smooth_canadian.jpg
<ogra_> s/hs/he/
<ogra_> canadians dont argue :)
<wookey> the likeness is extraordinary
<ppisati> section_image="universe/base"
<ppisati> and
<ogra_> (like germans arent srcastic)
<ppisati> do_debug="Yes"
<ppisati> are missing
<ppisati> will the world crumble?
<infinity> ppisati: Hrm?
<wookey> if someone is fettling kernels can they put https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1105251 in please
<ubot2> Launchpad bug 1105251 in linux "Fix cross- linux-tools build" [Medium,In progress]
<ppisati> *grumble
<infinity> ppisati: That section/image was a blatant lie, since omap was in main.
<wookey> I've just had to move it all forward to 3.9
<infinity> ppisati: However, the bootloaders var is much more troublesome.
<ppisati> infinity: becase it'll put a dependency on all those packages, isn't it?
<infinity> ppisati: Well, it could be fixable with [arch] restrictions.
<infinity> ppisati: Since that's ending up in a control stub, which then gets parsed by dpkg-gencontrol.
<ppisati> infinity: bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1) | [armhf]flash-kernel" ?
<infinity> ppisati: So, if all the current ones get [i386 amd64 x32] on them, and then you add "flash-kernel [armhf arm64]"
<ppisati> bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1) | flash-kernel [armhf arm64]"
<infinity> You need to arch-restrict all the x86 ones too.
<infinity> Or your arm builds will get deps on all of that.
<ppisati> infinity: ok
<infinity> (Some day, we'll want grub on arm anyway, but that day isn't today)
<ppisati> bootloader="grub-pc [i386 amd64 x32] | grub-efi-amd64 [i386 amd64 x32] | grub-efi-ia32 [i386 amd64 x32] | grub [i386 amd64 x32] | lilo (>= 19.1) [i386 amd64 x32] | flash-kernel [armhf arm64]"
<infinity> ppisati: Anyhow, it's a bit hard to sort out how this will all parse out through the build system, so do a quick smoketest on both x86 and armhf and see what the actual deps on the .deb end up being.
<ppisati> infinity: i'll do
<ppisati> infinity: and, about the provides=''
<infinity> ppisati: That seems reasonable.  (Probably worth rewriting somehow so that can be less messy, but it's a bit of a "who cares", if this works)
<ppisati> infinity: i think those are wrong for armhf too
<ppisati> provides="kvm-api-4, redhat-cluster-modules, ivtv-modules"
<infinity> ppisati: We surely build the same modules on armhf as x86.  If not, we should.
<infinity> ppisati: So, the only lie there is kvm-api-4.
<infinity> ppisati: Which kinda doesn't matter.
<ppisati> ok, lemme try to pt it tgether and do a compile
<infinity> ppisati: (And will stop being a lie with A15s)
<infinity> Well, once the kvm/arm code lands upstream.  They've not been as awesome as the Xen guys. :P
<ogra_> erm, where does that flash-kernel dep come from ?
<ogra_> we never had kernels depend on f-k
<ogra_> or did i miss omething
<ogra_> s
 * ppisati goes to eat an apple
<infinity> ogra_: https://launchpad.net/ubuntu/raring/armhf/linux-image-3.8.0-13-omap/3.8.0-13.23
<infinity> ogra_: Sure looks like it recommends flash-kernel currently.
<ogra_> hmm, i thought we were denied doing that
 * ogra_ remembers a heated discussion a few years ago when he wanted it like that for chroots 
<infinity> omap4 does as well.
<ogra_> well, good then
 * ogra_ sighs about his discussion in -desktop ... so debconf is dead ... since systemd uses "he POSIX way" of writing timezone data directly to /etc/localtime
<ogra_> s/he/the/
<ppisati> ok so
<ppisati> dpkg -i works
<ppisati> but flash-kernel is not aautomatically called
<ppisati> what shall i check?
<ppisati> infinity: ^
<infinity> Erm, was it called with the omap kernel?
<infinity> If so, nothing should have changed.
<infinity> flash-kernel should have poop in /etc/kernel/postinst.d/ that triggers.
<ppisati> lemme se if it's called with -omap
<ppisati> flash-kernel: deferring update (trigger activated)
<ppisati> when does it get called?
<infinity> ppisati: It's called from /etc/kernel/postinst.d/, like I said.
<ppisati> infinity: actually it's not called
<infinity> ppisati: Which is called from the kernel postinst.  Which shouldn't have changed at all.
<ppisati> infinity: flash-kernel: deferring update (trigger activated)
<ppisati> infinity: deferred to when?
<ppisati> infinity: when i type 'reboot'? don't think so
<infinity> Deferred to when the dpkg run is done, in theory.
<infinity> The trigger could be broken. :P
<ppisati> infinity: ah k
<ppisati> infinity: that makes more sense
<ppisati> infinity: anyhow, same behaviour as with omap
<infinity> Kay.  So, if anything's wrong, it's a flash-kernel bug, that's fine.
<ppisati> infinity: lol
<infinity> Did you do a build on both armhf and i386?
<ppisati> infinity: yep
<infinity> And if so, did you check the Recommends for each?
<infinity> "dpkg-deb -I foo.deb | grep ^Recommends"
<ppisati> infinity: lemme see
<ppisati> ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_amd64.deb | grep ^Recommends
<ppisati> ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_armhf.deb | grep ^Recommends
<infinity> That might need a space. :P
<infinity> "dpkg-deb -I foo.deb | grep '^ Recommends'"
<ppisati> ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_armhf.deb | grep "^ Recommends" Recommends: flash-kernel
<ppisati> ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_amd64.deb | grep "^ Recommends" Recommends: grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1)
<ppisati> looks good
<infinity> Shiny.
<xnox> nice
<ogra_> nephew
<mjrosenb> is it expected that I can have libexpat1-dev:armel and libexpat1-dev:amd64 installed at the same time?
 * Snark would say it's the point of multiarch
<ogra_> thats the purpose of multiarch, yes
<pizzacoca> hi guys, may someone have time to help I ve got a pb on my N7
<pizzacoca> ?
<ogra_> what is it ?
<pizzacoca> I made the install following
<pizzacoca> https://wiki.ubuntu.com/Nexus7/Installation#Troubleshooting
<pizzacoca> but on boot there was lots of cmd lines saying unable to write blabla filesystem readonly
<pizzacoca> https://wiki.ubuntu.com/Nexus7/Installation#Troubleshooting_the_Install
<pizzacoca> I wait until cellbatt goes down nothing happened, only scroll of theses lines
<pizzacoca> I just tried to boot it again it is still telling blabla readonly filesystem blabla
<pizzacoca> Is that's meaning my first install  went wrong ?
<pizzacoca> It took a long time during the
<pizzacoca> $ fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img command
<ogra_> pizzacoca, yes, that means somethign went wrong
<ogra_> check the md5sum of the img file
<pizzacoca> ok, so I'll try again the install ... another thing, not really about ubuntu install : wen I listen very close to my N7 I can hear some sound from it (like the hp's always buzzing) knowed issue on N7 ?
<ogra_> nope
<pizzacoca> thanks ogra, I'll see that
<ogra_> bug 1132439
<ubot2> Launchpad bug 1132439 in touch-preview-images "Android and iOS have majority of the phone market share" [Critical,Confirmed] https://launchpad.net/bugs/1132439
<darkfader> lol
<darkfader> this is so funny, because you can't close-wontfix without becoming a joke
#ubuntu-arm 2013-03-22
<Snark> hi
<discopig> hi
<cjwatson> I'm trying to get sbuild working on my Nexus 7 running the touch developer preview (because it's the most convenient reasonably modern ARM device I have root on - I'm doing non-touch-related stuff).  However, I can't debootstrap because the relevant filesystems are mounted nodev.  Remounting them dev, even from adb shell, doesn't seem to change anything.  Does anyone know how to work around this?
<ogra_> ugh
<ogra_> adb should definitely override
<ogra_> does mount still show it with nodev after a remount ?
<cjwatson> no
<ogra_> cjwatson, did you mount /procc inside the container ?
<ogra_> its not there by default due to PID namespace issues afaik
<cjwatson> I'm sshed in
<cjwatson> I thought that was enough
<cjwatson> seems to be there from ssh
<ogra_> dont trust mtab :)
<ogra_> cat /proc/net/dev ... see if the third level exists
<cjwatson> it does
<ogra_> if not, it isnt mounted
<ogra_> hmm
<cjwatson> I suspect maybe that the remount is ineffective because /data was already bind-mounted in some twisty way
<ogra_> oh, yeah
<cjwatson> is it possible to get the android layer not to mount it nodev in the first place, and then I can reboot?
<ogra_> well, yes, if you reboot the android layer
<ogra_> err
<ogra_> rebuild
<Tassadar> cjwatson: you can edit the ramdisk, I think there is normal fstab file
<cjwatson> ah, /init.rc maybe
<ogra_> the mounting is done from /init.rc
<ogra_> and init.rc is put in place from the initramfs
<ogra_> you cant just edit it
<Tassadar> I can do it for you if you send me the boot.img, It is like 5min of work for me since I do it quite often
<cjwatson> Gotcha.  Can I unpack/modify/repack the initramfs in-place?
<ogra_> (fstab as well, they are both copied from initrd)
<cjwatson> Tassadar: I'd rather know how to do it myself :)
<Tassadar> okay
<cjwatson> (though thanks)
<ogra_> you should be able to dd /dev/mmcblk0p2 to a file
<ogra_> then you should be able to disassemble it with abootimg
<ogra_> into initrd/kernel/config
<ogra_> and indeed re-assmble it the same way
<cjwatson> no /dev/mmc*
<ogra_> oh, android
<ogra_>  /dev/block/mmc*
<cjwatson> ok, let's see
<cjwatson> hmm, so I dded that out, unpacked, edited ramdisk/init.rc, repacked, updated boot.img with the repacked initrd.img, dded that back to /dev/block/mmcblk0p2, rebooted - no change
<cjwatson> after rebooting, /init.rc still has the original unchanged line in place
<ogra_> weird, it should update from the initrd
<cjwatson> well, I conclude that I didn't successfully update the initrd, but I don't know why
<Tassadar> I'm pretty sure there is fstab file in the ramdisk
<ogra_> did you edit fstab too ?
<cjwatson> that's not really relevant since the basic problem is that my init.rc change didn't take effect at all
<ogra_> init.rc just calls something like "mount /data"
<Tassadar> init.grouper.rc actually does "mount_all thenameofthefstabwhichIforgot"
<cjwatson> not so
<ogra_> fstab defines the options
<cjwatson>     mount yaffs2 mtd@userdata /data nodev
<ogra_> hmm
<Tassadar> that's not it
<cjwatson> there is an fstab but it doesn't go near /data
<ogra_> no, we definitely dont use yaffs ...
<ogra_> there should be an ext4 mount
<ogra_> look if tehre is an fstab.grouper or so
 * Tassadar goes to grab boot.img to see what is actually inside
<ogra_> and init.grouper.rc
<ogra_> that overrides
<cjwatson> well, there is an fstab.grouper, so I'll edit that.  That still doesn't explain why my init.rc change was ignored though
<ogra_> yeah
<Tassadar> tell us what you did to rebuild the boot.img
 * ogra_ guesses just using abootimg 
<ogra_> since thats what i suggested
<Tassadar> yeah, ubuntu touch has fstab.grouper, just like normal android
<cjwatson> abootimg -x boot.img; sudo abootimg-unpack-initrd; vi ramdisk/init.rc; sudo abootimg-pack-initrd -f; abootimg -u boot.img -r initrd.img
<ogra_> abootimg -u boot.img -r initrd.foo
<ogra_> yeah
 * cjwatson tries again
<ogra_> oh, where do abootimg-(un)pack-initrd come from
 * ogra_ didnt know these
<cjwatson> the abootimg package
<ogra_> must be new :)
<ogra_> i still use zcat/cpio usually
<ogra_> but i guess they just do the same
<cjwatson> yeah, I figured I might as well use them to get cpio options right
<cjwatson> Aha, that did it!  Thanks
<cjwatson> I guess I must just have failed to write back the modified boot.img before, somehow
<cjwatson> Sorry for the noise
<ptl> anyone here got an arndaleboard?
<ptl> ok :(
<XorA> ptl: yes
<Martyn> Cortex A15 question
<Martyn> Which platform is recommended for testing A15 + Ubuntu?
<Martyn> Which dev boards are known to work?
<ogra_> chromebooks are used by community people pretty widely
<Martyn> ogra : the XE303?
<ogra_> the arm one
<ogra_> i dont think there is more than one
<Martyn> Yeah, dual core Samsung Exynos chip
<ogra_> right
<Martyn> Okay.. Hmm..
<ogra_> the dev board equivalent is arndala i think
<ogra_> *arndale
<Martyn> *nod*
<Martyn> I just got a new devboard, and I wanted another platform to compare it to
<ogra_> nice
<infinity> Yeah, the Xen guys have been doing all their work on Arndales and Chromebooks.
<Martyn> since getting Ubuntu up and running on this platform will take me a couple weeks
<infinity> I'm not really aware of any other widely-available A15s.
<Martyn> infinity : There are none, that I am aware of.
<ogra_> nexus4
<Martyn> infinity : I'd like to change that, but getting production-run quantities of A15 chips is hard
<Martyn> nexus 10 has the exynos 5 as well
<ogra_> right
<Martyn> but that's not a platform I'll be comfortable poking at
<Martyn> I'm talking to nVidia now
<Martyn> since there's exactly 0 chance of getting TI chips
<ogra_> why not ?
<ogra_> omap5 is on sale
<ogra_> in the new evm board
<Martyn> Because I can't get a volume production quantity from TI
<Martyn> and the IP they chose to put on the OMAP doesn't map well to an ATX form factor PC
<Martyn> Also, PowerVR driversâ¦ always an issue
<Martyn> Nvidia at least handles OpenGL 4.x
<ogra_> https://www.svtronics.com/index.php?route=product/product&product_id=33
<ogra_> the pandaboard that wasnt called panda ...
<Martyn> Yeah
<Martyn> Saw it
<Martyn> The nvidia tegra4 T42 will probably end up being the chip though
<Martyn> quad + 1, 2.0GHz has been verified and validated
<Martyn> The @#$@#$ thing is the lack of PCIe on all platforms
<infinity> No PCIe on the Tegra4?
<infinity> Even the Tegra2 had PCIe.
<infinity> That's what the Trimslice's SATA hangs off of.
<ogra_> really ?
<Martyn> just like on the EnergyCore, it's got lockup issues
<ogra_> i thought i saw PCIe mentioned
<Martyn> It's the stupid AMBA bus to PCIe bridge that fails, when it gets out-of-order transactions
<Martyn> locks up the AMBA bus, and that's that
<infinity> Brilliant.
<Martyn> If you look at the latest IO block diagram for the Nvidia, you'll see that I/O no longer lists PCIe
<infinity> Kernel bug, or fundamental design flaw?
<Martyn> fundamental design flaw, on die, in chip
<infinity> \o/
<Martyn> workarounds require changes to the chip
<ogra_> thats what you call progress :)
<Martyn> (adding a method to reset the bus)
<Martyn> It's why Calxeda doesn't really acknowledge that there is a PCIe block on the die
<infinity> I've said it a few times this year already, but I can't wait to see what sort of ARM silicon AMD spits out.  They can't possibly get so many things wrong.
<ogra_> probably a fallout of not having a device partner at all
<Martyn> same with Tegra
<Martyn> same with NEC
<Martyn> ogra : Has to do with using the Synâ¦ys IP
<Martyn> Hey, at least the 10GigE works :)
<infinity> (Though, AMD has no plans for armv7 AFAIK, only armv8... Maybe they'll surprise me and do both)
<Martyn> What's the other thing I need to have working .. one or two GigE interfaces are kind of "a requirement" when building ATX machines
<infinity> Martyn: If I had an ARM board with two GigE devices that could actually saturate both links, full duplex, I'd be a very happy man.
<Martyn> infinity : Calxeda has that
<Martyn> Get an EnergyCore card
<ogra_> get ... heh
<infinity> Erm, does anyone make single EnergyCore anything?
<infinity> I don't need blades, I want a router. :P
<Martyn> No, but you can ask Calxeda for one of the little dev boards
<Martyn> it can take as little as one board
<Martyn> It was originally called a "slingshot" when the first prototype boards were brought in
<infinity> If I knew how to get such a dev board, I'd already have one.
<Martyn> infinity : just ask.
<Martyn> Talk to Karl
<ogra_> well, there is that "get" thing :)
<infinity> Care to introduce us? :P
<ogra_> asking is cheap
<Martyn> Unless things have changed so much .. I know that Calxeda joined the whole Linaro thing, so I know the platforms are out there
<Martyn> Also, you can go play with it on the OpenStack instances they have available for public playtime
<ogra_> thats a great idea !
<infinity> Bonus points if those boards boot and look vaguely like a card in a full chassis.  Would make my life so much easier, trying to do various crackful things.
<Martyn> start up two instances, and talk to each other.  They are likely going to be on two wholly different boards on the cluster
<ogra_> infinity, run your router in an openstack instance !
<Martyn> ogra : Should work, right?
<infinity> Martyn: Openstack sort of defeats the purpose for me, since I'm interested in being next to the metal, not abstracted away.
<Martyn> EnergyCore's are physicalized, not virtualized .. so he'll be playing with real hardware, at the metal
<Martyn> ^^
<Martyn> infinity : That's the whole POINT of running ARM on OpenStack .. you're physicalized, not virtualized
<Martyn> You're in a jail, and if things are still like when I was at Calxeda, it's using LXC
<infinity> Maybe I misunderstood, I thought current openstack-on-arm was lxc trickery and the like.
 * ogra_ kind of wasnt serious about running a router in a  foreign cloud instance
<Martyn> so you're going to be on the metal
<infinity> lxc is not "next to the metal".
<Martyn> infinity : Close enough.   Certainly closer than if you were on KVM
<infinity> I'm interested in booting and installing bare systems, not playing in containers.
<Martyn> you're basically just in a fancy jail
<infinity> I have tons of ARM hardware to screw around in userspace with.
<Martyn> meh, fair enough
<Martyn> but if you want to play with a platform that lets you pump >1Gigabit on ARM, Calxeda is the only platform I can think of capable
<Martyn> and LXC won't abstract you or slice you away from that
<infinity> Yeah, two disparate goals there. :)
<Martyn> you'll still have full access to the interfaces, and fabric
<infinity> One goal is better/shinier enablement, which needs me to sit next to the metal.  And I think I might honestly just take a flight to Boston and play with some of our crap in the datacenter there.
<infinity> The other goal is a personal home router.
<infinity> So, again, need real hardware for that, cause running my home router in an LXC container in another city might not work so well. ;)
<Martyn> Ah, hold on .. looks like the SnapDragon also supports PCIe
<Martyn> 3.0
<infinity> And, to be fair, I don't need full saturation for the home router, my internetses are only 250 Mbit.
<infinity> But that still demands more than I can get out of any ARM boards in my house.
<Martyn> IP is by Global ...
<Martyn> Hmm .. is there even PCIe support in the Linux SnapDragon kernel?
<infinity> Is SnapDragon multiplatform enabled yet?
<infinity> Not that that's relevant to the question, per se, but it probably makes PCIe enablement slightly more likely.  Unless it's wildly different from other SoCs in how it works.  Which it might be.
<Martyn> Mrrf.
<Martyn> Well, found a snapdragon dev board
<Martyn> ex-pen-sive doens't even begin to describe it
<Martyn> This is as expensive as the ARM development platforms for A15 when it first came out .. the one with the big Xylinx Spartan 7 on it
#ubuntu-arm 2013-03-23
<suihkulokki> m,.Ã¤-Ã¶:-) ,,:-) :-) mnÃ¤bbbv.
<kulve> suihkulokki: agreed
<angs> I have an ubuntu-server (uname -a > Linux ubuntu 3.2.0-23-omap #36-Ubuntu Tue Apr 10 20:24:21 UTC 2012 armv7l armv7l armv7l GNU/Linux)is there any website that I can download wpa_supplicant 2.0 that is built for ubuntu-arm?
<angs> when I execute  apt-get build-dep  wpasupplicant. what version of wpasupplicant's dependencies are installed?
<ogra_> the deps for the version in the archive indeed
<ogra_> since thats all apt knows
<angs> is it the archive you mentioned http://packages.ubuntu.com/search?keywords=wpasupplicant&searchon=names&suite=precise&section=all
<angs> ogra_, have you prepared the prebuilt ubuntu-server image for beagleboard?
<ogra_> about three years ago, yes ...
<ogra_> i dont think anyone touched it since
<angs> I would like to use SPI on beagleboard but ls /dev does not show the spi device.
<angs> then I am using your image on beagleboard-xm
<ogra_> heh, brave :)
<angs> is SPI enabled by default on your image on beagleboard?
<ogra_> if you miss something, file a bug ...
<ogra_> no idea, as i said, its three years ago i touched any beagle stuff last
<angs> ok thank you :)
<ogra_> but missing SPI sounds like it simply needs a flip of a kernel config option ...
<ogra_> so a wishlist bug against linux should help
<angs> I checked the config files, you open the spi options as modules, do you know which module out of these options I need to load http://pastebin.com/wtNxbkRU to be able to connect a SPI device?
<ogra_> hmm, no, probably ask in #beagle
<angs> thank you
<Se7enLC> I tried out ubuntu for nexus7, then went back to android. Problem is, now my 16GB nexus 7 thinks it's an 8GB. Any ideas?
<Se7enLC> nevermind, figured it out. I jumped directly to a ROM, but I should have gone back to a stock image with fastboot first
#ubuntu-arm 2013-03-24
<suihkulokki> kulve :)
<Snark> hi
<Snark> http://trac.sagemath.org/sage_trac/ticket/14335#comment:5
<Snark> ^^ there are warnings because libm4ri doesn't know how to properly detect L1/L2 cache on ARM
<Snark> how does that work?
<Snark> is there a simple example somewhere where I can point the libm4ri developper to?
<subash> hi. i am trying ubuntu 12.04 desktop preinstalled version on my beagleboard xm. i want to use the personal file sharing. i am not able to make the board to receive files from my phone.
<subash> is there any package apart from obex i need to install?
<subash> thanks in adavance
<marvin24> since today I get: cbootimage: cbootimage.c:156: main: Assertion `g_soc_config != ((void *)0)' failed.
<marvin24> on raring
<marvin24> this is just running "cbootimage -h"
<marvin24> which prints the help text of a program
<marvin24> SIGABRT in libc
<infinity> libc doesn't relate at all, it's just raising the abort().
<infinity> The assertion at cbootimage.c:156 is what you might want to look at. :P
<infinity> And since I have no idea where cbootimage.c is from...
<infinity> marvin24: There is a new glib2.0 in raring.  Wild shot in the dark based on the g_* naming in your assertion up there, but perhaps something changed subtly.
<marvin24> infinity: cbootimage just links against libc
<marvin24> source: https://launchpad.net/~ac100/+archive/ppa/+packages
<marvin24> infinity: ok, maybe my fault
<marvin24> or better upstreams fault
<infinity> *nod*
<jimerickson> getting "omapdss dpi error: could not enable display: no manager" with todays omap4 image on pandaboard ES. after that message it leaves me with a blank screen and blinking cursor.
<Qrchack> hey all
<Qrchack> anyone being on linux with GCC & ARM target here?
<Qrchack> i do need some help with cross-compiling ext2 kernel module for ARM
#ubuntu-arm 2014-03-18
<salaet> Hi
<salaet> Anybody can help me ? I want to install ubuntu on BeagleBoneBlack with minimal image without any x, like server.
<salaet> wich is the correct image for this purpouse and I can look the repository to know wich package are in?
<salaet> thanks
<salaet> and where is the repository url. .. I'm googlin but I cant find
<ogra_> salaet, i think infinity and ppisati were working on making official installer images, not sure how far they got though
#ubuntu-arm 2014-03-19
<Martyn> Afternoon all
<Martyn> It
<Martyn> It's been a long, long time :)
<Martyn> It's been sad that there have been no more physical summits ... that used to be one of the big highlights of the year for me :)
<Martyn> The online summits just aren't the same :)
<applepi> Hi all..  Maybe I'm just missing it, but where could I find the prebuilt ubuntu rootfs images?
<applepi> Is it necessary to deboostrap it?  I was of the understanding a stock armhf image existed.
<infinity> "ubuntu-core" is a rootfs tarball with no kernel, if that's what you're after.
<infinity> applepi: http://cdimage.ubuntu.com/ubuntu-core/releases/
<applepi> infinity: okay..  if I wanted to get ubuntu running on an SD card on an ARM board, with as little pain as possible, what instructions should I follow?  I've found several different images, methods, suggestions, etc., and nothing works.
<infinity> applepi: If it's a device we don't support, the answer is something like "you're on your own".
<infinity> applepi: And I suspect that's the case for you.  So, you need to provide the bootloader and kernel, then jam that into a rootfs (like the above) and see what happens.
<infinity> applepi: Every device is different, so there aren't really any sane written instructions I could even write to tell you how to do that generically.
<applepi> infinity: should the generic kernel and rootfs not work?
<infinity> applepi: The generic rootfs will work fine.  The generic kernel almost certainly not, unless it's one of the few devices supported by it.
<applepi> infinity: I have the device tree for it, and from what I understood, support for the chipset was enabled in the generic kernel.
<infinity> applepi: What is "it"?
<applepi> infinity: mx6slevk
<infinity> Ahh, well, then, "maybe".
<infinity> mx6 support is on in our kernel but not all boards are completely enabled, I suspect.
<infinity> stgraber may know more, but he seems to be avoiding this channel today. :P
#ubuntu-arm 2014-03-20
<crawler2014> hi folks :)
<crawler2014> I was wondering whether I could contribute some things to get ubuntu / ubuntu touch working on RK3188-based tablets like the Vido N90 I have
<crawler2014> I could provide the partition scheme and boot options, firmware files if needed :)
<crawler2014> anyone?
#ubuntu-arm 2014-03-21
<Proshot> evening everybody
#ubuntu-arm 2014-03-22
<Valduare> hi guys I have an mk802iiis running ubuntu, as I understand it the resolutiosn are hardcoded in the kernel
<Valduare> i seem to be set at 1080 p resolution and iâd like to switch it to 720 p wich is also supported. I just dont know how..
<Valduare> any ideas?
#ubuntu-arm 2014-03-23
<TuxOholic> hello, anybody knows a toolchain library for libblkid-dev, liblzo2-dev, uuid-dev, zlib1g-dev ?
<TuxOholic> all build dependencies for btrfs-progs
<ogra_> apt-get install build-sessential && apt-get build-dep btrfs-tools
<TuxOholic> i'm cross compiling from x86 for armhf using arm-linux-gnueabihf
<ogra_> that should give you all you need (if you run it on an arm system ... if you cant, use qemu-debootstrap (from qemu-user-static) to create an armhf chroot)
<TuxOholic> so qemu will allow me to pretend i'm on arm arch? - how much does this install into the chroot?
<ogra_> a base system
<TuxOholic> is that ~500MB or how much?
<ogra_> less
<TuxOholic> 250?
<ogra_> 80-100 i would guess
<TuxOholic> okay
<ogra_> plus whatever the build-deps pull in indeed
<TuxOholic> build-depends are almost nothing, so i'll try this one, thanks ogra_
<rigo88> hi. can i install on Linux cubieboard-server 3.4.43 #1 PREEMPT Wed May 29 13:37:24 CST 2013 armv7l armv7l armv7l GNU/Linux the .deb kernel files from kernel.ubuntu.com/~kernel-ppa/mainline/?
<rigo88> http://paste.ubuntu.com/7142316/
<infinity> rigo88: given that those kernels are only built for x86, seems pretty unlikely.
<infinity> But even if there were ARM ones, I doubt they'd support your device.
<rigo88> i c. how can i update then to the latest kernel? or is the 3.4.43 the latest?
<infinity> rigo88: The latest I see from cubieboard.org is 3.4, no idea if anyone's worked on anything newer.
<rigo88> gr8. thanks. so i install the required packages and try to install the s2-liplianin-v39 on this distro too. i had no luck on cubian-debian they told me the headers are broken or what..
#ubuntu-arm 2015-03-17
<limbonic> hi all! I need some help with ubuntu snappy
<limbonic> I have successfully run snappy core with my beaglebone black
<limbonic> and I have play with the sample apps
<limbonic> I try now to write my own app that blinks an LED
<limbonic> I use python, but my problem is I dont know how to install Adafruit_BBIO library for the GPIO pins
<limbonic> i try to find something relevant in the documentation
<limbonic> but no luck...
<limbonic> anyone that can help me?
<ogra_> limbonic, go to #snappy
<limbonic> thank you :)
<ogra_> :)
#ubuntu-arm 2015-03-19
<jo-erlend> I have a project that I need an ARM board for. I need one USB 3 Host and one USB 3 OTG. Other than that, it should be as small, simple and cheap as possible. Am I asking too much, or does anything like that exist?
#ubuntu-arm 2015-03-20
<jo-erlend> The ODROID XU3 seems very nice. Think I'll get one of those.
<BeagleBug_97> Hi, is it possible to install rt-preempt patch on Ubuntu 14.04 running on BeagleBoard xM?
<ogra_> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<BeagleBug_97> Thank you, i had gone through the link. Just wanted to make sure someone had tried it before I attempted.
<ogra_> well, you could ask in #ubuntu-kernel ... they can surely give you more info if needed
<BeagleBug_97> +1
<Guest59_> anybody here ?
<PetrLeoCompel> Guys im trying boot ubuntu on TF201
<PetrLeoCompel> but after load it will fire kernel panic
<PetrLeoCompel> TF201 kernel panic :P
<genii> Were you following the instructions at http://forum.xda-developers.com/showthread.php?t=1603921 ?
<PetrLeoCompel> geni: no they are very old
<PetrLeoCompel> genii: now i get over it
<PetrLeoCompel> genii: but now im getting error with /proc mount
<PetrLeoCompel> Good night)
#ubuntu-arm 2015-03-22
<PetrLeoCompel> anybody who have experiences with tegra ?
#ubuntu-arm 2016-03-22
<ndec> hi ogra_, what is this url? https://github.ubuntu.com/96boards/linux , it's mentioned here: http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/
<ogra_> ndec, ask sergiuens (in #snappy) ?
<ndec> well, i am asking you, because I got the link from you ;-)
<ogra_> but i didnt write that blog post
<ogra_> i guess it was given to him at connect
<ogra_> oh
<ogra_> now i clicked it :P
<ndec> yeah.. it doesn't exist ;-0
<ogra_> ndec, thanks, forwarded :)
<ndec> good.. ;-)
 * ogra_ sees the headlines already "canonical preparing to take over github"
 * davmor2 buys a gag for ogra_ fingers in order to stop the rumour mills
<ogra_> heh
#ubuntu-arm 2016-03-26
<caden> Hello, I am having a problem with my Raspberry Pi 2B's audio. It is very touchy and requires fiddling around with the volume keys on my keyboard to get it to work right. Help?
#ubuntu-arm 2017-03-20
<genii-netbook> For Samsung ARTIK7, use the ARTIK10 install? https://developer.ubuntu.com/core/get-started/artik-5-10#alternative-install:-ubuntu-server-16.04-lts
#ubuntu-arm 2017-03-22
<TheHexaCube> hey folks o/
<TheHexaCube> I have a (hopefully) quick question - are there any recommendations/well supported 7" tablets, if I want to install ubuntu/linux on it?
<TheHexaCube> I was recommended to look for allwinner tablets, but so far I could only find A33 tablets, which don't seem well supported at all
#ubuntu-arm 2017-03-24
<Guest47281> raspbian on rapi3 get very slow with chrome . chrome heavy ? light web browser  ?
<k1l> Guest47281: i guess the #raspbian guys know about that
<ogra_> yeah, not realyl an ubuntu topic
<Guest47281> sorry guys
#ubuntu-arm 2018-03-25
<soshiant> i want link download repository for ubuntu trusty
