**** BEGIN LOGGING AT Tue Jan 18 02:59:57 2011 Jan 18 08:21:59 morning Jan 18 11:00:39 I was a little surprised to find that --sysroot was removed from binutils-arm-linux-gnueabi. I understand it conflicts with xdeb, but isn't it a drastic measure. It breaks the way we crossbuild ubuntu apps (that are not debian packages). How can I do so without sysroot? Jan 18 11:02:49 hrw: ^ Jan 18 11:03:21 sveinse: I Jan 18 11:03:43 sveinse: I'm not sure which exact sysroot you mean; you mean with the support for --sysroot, or with a specific sysroot setting? Jan 18 11:03:51 sveinse: sysroot was not enabled in lucid time too Jan 18 11:04:11 I think we just fixed the linker path to look in the right dirs, and didn't need the sysroot hack; but if --sysroot is useful, it should be enabled in both ld and cross-ld builds Jan 18 11:04:19 Doesn't really relate to what we do though Jan 18 11:05:02 sveinse: did you used 10.04 or only 10.10? Jan 18 11:05:34 10.10 Jan 18 11:07:02 after sysroot was enabled, we have found a realiable way to build non-deb apps for ubuntu target Jan 18 11:09:31 basically we have a armel rootfs which we sysroot ld with "--sysroot=/home/user/rootfs-dev -L=/lib -L=/usr/lib" Jan 18 11:10:05 sveinse: if you do not use xdeb then use binutils from maverick not from maverick-updates Jan 18 11:10:14 As mentioned in #692987 we pin against 2.20.51.20100908-0ubuntu2cross1.50 to keep our buildsystem up and running Jan 18 11:10:25 sveinse: sysroot support was enabled by mistake in 10.10 Jan 18 11:10:56 I got it sneaked in during doing lot of changes in whole toolchain Jan 18 11:11:01 So basically, this (sysroot) is something we will never have then? Jan 18 11:11:17 not in official packages Jan 18 11:12:09 Thats too bad because the other cross compiler alternative, CSL, has a different libc configuration which makes problems during starting of apps on target Jan 18 11:12:39 The beauty of the ubuntu cross compiler is the fact that it is harmonized with the native compiler/libs on target Jan 18 11:13:47 So I raise my question again then: How can we cross build non xdeb apps for ubuntu target? Jan 18 11:15:20 I'd be happy to blog about how we managed to build apps for ubuntu target, but I don't know how relevant this is now if sysroot is a mistake... Jan 18 11:15:43 Nor how we shall continue to build our apps Jan 18 11:17:24 sveinse: use xapt to install cross libs and do compilation Jan 18 11:17:42 xapt will fetch armel libs, mangle them and install to /usr/arm-linux-gnueabi/ dir Jan 18 11:17:50 compiler will look there Jan 18 11:17:53 linker too Jan 18 11:18:13 and then you can copy results into your device Jan 18 11:18:32 sveinse: so instead of installing into your sysroot you install into system Jan 18 11:18:58 thanks, I'll look into it! Jan 18 11:20:05 hrw: Do you happen to have a description of how somewhere? As a kickstart, I mean. Jan 18 11:20:21 "xapt -aarmel install ncurses" or sth like that Jan 18 11:20:36 I used it once and it was easy Jan 18 11:21:27 does this setup a fakeroot environment somewhere? ok.... I'll read myself up on it before asking 10000 questions. Jan 18 11:21:48 no, it will not give you copy of rootfs Jan 18 11:22:00 this one you need to generate. rootstock does it Jan 18 11:22:07 or multistrap Jan 18 11:22:44 Yes, I'm using rootstock to make the rootfs I use sysroot against, so that part is known Jan 18 11:24:04 Have to leave. Back in 45 mins.. **** BEGIN LOGGING AT Tue Jan 18 14:13:58 2011 Jan 18 14:14:30 rsalveti: I'd like to add an IGEP build as well Jan 18 14:15:25 rsalveti: Not sure that's supported though Jan 18 14:15:31 rsalveti: Overo would also be helpful Jan 18 14:19:00 rsalveti: Seems IGEP was submitted and fixed; anything preventing its merge? Jan 18 14:27:40 rsalveti: How do I contribute to your x-loader packaging to add an overo flavor? Could we keep it in Launchpad instead? Jan 18 14:30:48 lool: hey Jan 18 14:31:11 lool: are final, and it'd be ok to add igep as well Jan 18 14:31:48 rsalveti: Can you commit to the main x-loader tree to add IGEP? Or would you be ok to pull them in the Ubuntu tree? Jan 18 14:32:08 lool: igep patches are still not merged Jan 18 14:32:57 lool: I'd prefer to wait the patches to be in the main tree first Jan 18 14:33:25 but if it takes too long we can for sure push it at the package itself Jan 18 14:37:18 Anand works in Linaro and announced the new x-loader stuff; I've emailed him to ask him for a review Jan 18 14:38:00 rsalveti: So, I'd like to contribute to the packaging, how do I do this? Jan 18 14:38:25 lool: and the only 2 flavors that were actually tested were beagle and panda Jan 18 14:38:25 even on the main tree Jan 18 14:38:25 that's why I just activated these 2 first Jan 18 14:38:45 rsalveti: the announcement said overo support should work Jan 18 14:39:02 thx to whoever fixed the kubuntu mobile natty builds Jan 18 14:39:03 Currently, thanks mainly to Steve's efforts, the tree builds for and Jan 18 14:39:03 works on the following platforms: the OMAP3 EVM, the Overo and Beagle Jan 18 14:39:03 (both 35xx and 37xx), and the Pandaboard. Jan 18 14:39:07 rsalveti: ^ Jan 18 14:39:34 well, it *should* work but as I don't have the hardware and nobody said that was using it, I didn't add it by default Jan 18 14:39:44 but ok, can easily activate it Jan 18 14:40:01 lool: I can move it to bzr if you want Jan 18 14:40:07 not something I actually like, but ok Jan 18 14:40:19 rsalveti: I don't mind either way, but I need some kind of way to update it Jan 18 14:40:46 rsalveti: Another option would be a gitorious team with a lot of Ubuntu Developers in it Jan 18 14:40:54 rsalveti: But we should leverage launchpad for packaging really Jan 18 14:41:04 rsalveti: Up to you, just tell me where to commit Jan 18 14:41:17 I can work with either git or bzr, just can't commit to ~rsalveti obviously ;-) Jan 18 14:41:22 its more upstream stuff whats in gitorious, no ? Jan 18 14:41:35 ogra: not in my tree Jan 18 14:41:39 ogra: It's just a git hosting place; you can think of it like Launchpad -- merge requests etc. Jan 18 14:41:39 ah Jan 18 14:41:48 I have 2 trees, one for upstream work and another for packaging Jan 18 14:41:48 Just like github Jan 18 14:41:54 lool, i know what gitorious is Jan 18 14:41:58 i was referring to rsalveti's branch Jan 18 14:41:58 :-) Jan 18 14:42:09 lool: will move to LP, will make it easier Jan 18 14:42:16 lool: ping you back when I'm done Jan 18 14:42:19 rsalveti: thanks Jan 18 14:42:43 lool: can you test overo? Jan 18 14:43:05 rsalveti: No, I gave them all away, but we have 6 tobi + overo in linaro Jan 18 14:43:09 or we'll be just creating the package without testing it? Jan 18 14:43:20 lool: can you ask someone to test current master tree? Jan 18 14:43:31 rsalveti: I'd rather have them test of the package Jan 18 14:43:45 That way we're testing binaries built with our in-archive toolchain etc. Jan 18 14:44:02 well, it's the same toolchain they are probably using at the desktop Jan 18 14:44:04 or at least should Jan 18 14:44:06 rsalveti: There's one u-boot build rule that is not in the x-loader rules which I suspect might be important Jan 18 14:44:21 lool: which one? Jan 18 14:44:38 rsalveti: jcrigby stripped -Bsymbolic from the LDFLAGS explicitly, noting that it broke relocation; I don't think your x-loader relocates, but it could have other side effects Jan 18 14:44:42 Maybe not though Jan 18 14:44:46 Just wanted to mention it Jan 18 14:45:03 rsalveti: Why do you assume it's borken? :-) Jan 18 14:45:21 rsalveti: Steve Sakoman was testing his tree regularly, and I think this tree started of his tree; Jan 18 14:45:27 lool: because the tree is new and nobody said to me it works :-) Jan 18 14:46:14 rsalveti: One thing I'd like to discuss in the future is merging the MLOs in a single package Jan 18 14:46:21 I think one package per board doesn't scale Jan 18 14:46:31 x-loader should die Jan 18 14:46:35 that too Jan 18 14:46:38 it's not going to get a lot more boards Jan 18 14:46:41 we have the same problem with u-boot-linaro though Jan 18 14:46:50 which is getting a lot of boards Jan 18 14:46:59 u-boot sure, not x-loader Jan 18 14:47:13 rsalveti: LP #702046 Jan 18 14:47:14 Launchpad bug 702046 in x-loader (Ubuntu) (and 2 other projects) "Overo support (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/702046 Jan 18 14:47:23 rsalveti: Well I'd rather have the same layout for x-loader and for u-boot Jan 18 14:47:34 it's essentually the same problem and we're shipping both in linaro hwpacks Jan 18 14:47:44 anyway, we have time to discuss this Jan 18 14:47:50 maybe we can move to IPL instead Jan 18 14:58:33 lool: one question, how is it done with the linaro packages at the archive? Jan 18 14:58:40 the ones that are mainly done at git.linaro.org? Jan 18 14:58:43 like u-boot? Jan 18 14:58:54 if you want to change it, for example Jan 18 14:58:57 or any other ubuntu developer Jan 18 15:01:06 rsalveti: Until now, I grabbed the u-boot-linaro source package and uploaded to the archive; last week, I saw that u-boot-linaro has a Vcs-Git; I checked that the branch had all my uploads and asked slangasek about it; I don't remember the outcome, but I want to chat with jcrigby to find out Jan 18 15:01:19 rsalveti: I don't want to commit to git://git.linaro.org/boot/u-boot-linaro-stable.git for package updates either Jan 18 15:01:51 well, at least with gitorious you can created a merge request Jan 18 15:02:15 so if any ubuntu dev want to change the package, it will probably need to send the patch to the owner, right? Jan 18 15:02:28 I Jan 18 15:02:52 I'm just trying to understand the packaging policy Jan 18 15:06:04 * rsalveti brb Jan 18 15:09:44 lool: ping? Jan 18 15:10:02 jcrigby: In a call, give me 30mn? Jan 18 15:10:26 sure, just saw my name mentioned Jan 18 15:53:16 jcrigby: pong Jan 18 15:53:30 jcrigby: Yeah, I wanted to ask about the u-boot-linaro packaging Jan 18 15:53:47 jcrigby: it's in git.linaro.org, which means other ubuntu developers can't commit it when updating Jan 18 15:54:09 jcrigby: Maybe we should just release u-boot-linaro tarballs monthly, or when we see fit, and maintain the packaging in a bzr branch on launchpad Jan 18 15:58:45 lool: for me git is easier and I'm willing to accept patches via email. How main ubuntu u-boot developers are there? Jan 18 15:59:23 jcrigby: Problem is the Vcs field Jan 18 15:59:50 jcrigby, I don't understand Jan 18 15:59:52 jcrigby: The usual workflow to work on a package with a Vcs field is something like debcheckout, hack, commit, upload; but they can't commit Jan 18 16:00:31 So they wont commit and the next person doing debcheckout will be looking at an old version of the package Jan 18 16:00:51 also, you risk uploading a new u-boot-linaro overwriting packaging changes which are only in the archive and not in git Jan 18 16:01:01 so lets just take it out of bzr completely Jan 18 16:01:05 bzr? Jan 18 16:01:16 I'm speaking of the git packaging branch Jan 18 16:01:19 is it in bzr?? Jan 18 16:01:27 no Jan 18 16:02:00 jcrigby: If instead we would put the packaging under a bzr branch owned by ~ubuntu-dev, anybody able to update the package in the archive woudl also be able to commit Jan 18 16:02:01 it could be in git, but then you need to add permission to every ubuntu developer Jan 18 16:02:08 or change to bzr and add ~ubuntu-dev Jan 18 16:04:05 how does the kernel deal with this same issue? Jan 18 16:04:19 the kernel doesnt use bzr at all Jan 18 16:04:28 they refuse to Jan 18 16:04:29 I think that was my point Jan 18 16:04:32 jcrigby: kernel is different Jan 18 16:04:35 why Jan 18 16:04:42 probably because they want :-) Jan 18 16:04:51 upstream u-boot is git Jan 18 16:04:58 I know, same as x-loader Jan 18 16:05:01 jcrigby: I personally don't like the fact that the kernel is different, it's an unfortunate exception Jan 18 16:05:35 jcrigby: A lot of upstream are in git, and while it's ok to have different Vcses for differnet packages, it's not ok to prevent the upload of more and more packages Jan 18 16:06:53 jcrigby: kernel team is also much larger :-) you are guaranteed to find a kernel developer every hour of the day, while you might personally go on leave :-) Jan 18 16:07:23 ok,so what needs to happen? Jan 18 16:07:45 lots of upstreams are git btw Jan 18 16:07:47 jcrigby: Well it could be a number of things Jan 18 16:08:13 ogra, I know, I just don't like bzr much Jan 18 16:08:31 jcrigby: Perhaps the simplest conceptually is to stop worrying about the packaging branch in git, kill it entirely, and use the Ubuntu archive and its corresponding bzr branches for history Jan 18 16:08:52 well, at some point bzr might become required to build a deb Jan 18 16:09:18 ogra, fine I'm willing to learn Jan 18 16:09:19 jcrigby: that way, you can either use bzr if you need to dig up history, or just apt-get source + hack + prepare a debdiff for sponsoring to get something uploaded Jan 18 16:09:37 Basically, you keep both the apt-get source option and the bzr option open Jan 18 16:09:57 but no git option Jan 18 16:10:00 Another way would be to start some gitorious/github team Jan 18 16:10:06 no Jan 18 16:10:09 and we'd add as many people who'd like to join to it Jan 18 16:10:24 but that wont ever match the set of people who can upload to Ubuntu Jan 18 16:11:03 so what prevents non packaging patches from being uploaded Jan 18 16:11:04 jcrigby: I expect the packaging updates of u-boot-linaro to be relatively straightforward from now on, so maybe it's not a big deal? Jan 18 16:11:13 jcrigby: Nothing prevents it Jan 18 16:11:24 jcrigby: And that's fine; gcc-linaro releases are patched before they go into Ubuntu Jan 18 16:11:34 and how do those non packaging patches go upstream Jan 18 16:11:40 jcrigby: Depends Jan 18 16:12:00 jcrigby: Sometimes they come straight from upstream, but didn't propagate into a tarball release yet Jan 18 16:12:10 jcrigby: Sometimes they are sent upstream by the person uploading to Ubuntu Jan 18 16:12:26 jcrigby: Sometimes they are quick workarounds which need another solution upstream, and only a bug is filed Jan 18 16:12:53 sometimes (if its a bad ubuntu maintainer) they arent forwarded at all too Jan 18 16:13:38 jcrigby: I think you had a lot of chats about this type of stuff with slangasek; I don't mind if you prefer getting his own explanation on this stuff; he is native and has usually better arguments than I do Jan 18 16:14:42 lool, for the latest release I thought we had arrived at a pure git solution Jan 18 16:15:36 jcrigby: Well, it's valid as long as you keep it to Linaro PPAs for instance Jan 18 16:15:58 jcrigby: Because people who can commit to git can also upload an updated package to the PPA and vice-versa Jan 18 16:19:53 lool: ok lets assume that all we get from git.linaro.org is a tarball which is upstream + linaro patches (if any) Jan 18 16:20:04 lool, and all packaging is in bzr Jan 18 16:20:27 jcrigby: Yup Jan 18 16:20:31 and someone commits and uploads a non packaging change Jan 18 16:20:38 Yes Jan 18 16:21:14 I notice the change and decide it needs to go upstream so I send it up and while waiting for upstream to accept it I also apply it to git.linaro.org Jan 18 16:21:23 Ok Jan 18 16:21:29 (You're being nice :-) Jan 18 16:21:39 as always:) Jan 18 16:22:09 so I do a new tarball release (maybe on demand or every two weeks) Jan 18 16:22:46 how do I do the bzr merge with the new tarball? Is that easy? Jan 18 16:22:52 jcrigby: it's easy Jan 18 16:23:02 lool, ok then I see no problem Jan 18 16:23:14 jcrigby: It will sound complex if I describe it to you on IRC, but it's really easy Jan 18 16:23:34 jcrigby: The main reason for complexity is the way in which the packaging changes are added Jan 18 16:23:51 jcrigby: For instance, the packager could either add a debian/patches/foo.patch Jan 18 16:24:14 or (s)he could just change the package tree and upload, that would end up in the diff Jan 18 16:24:48 right, in the foo.patch case then with new tarball they would just remove it? Jan 18 16:24:53 in the latter case, bzr might be able to see that the changes were merged upstream (not 100% sure); in the former case, the package would fail to build because the build would apply a patch which is already applied Jan 18 16:25:09 right Jan 18 16:25:12 so the packager would have to remove the patch when updating to the new tarball (which is what we usually do) Jan 18 16:25:20 ok Jan 18 16:25:46 lool, I see my bzr skills will need improving but that is fine Jan 18 16:26:02 jcrigby: Frankly, if you can git I don't see why you wouldn't bzr Jan 18 16:26:36 You can't even rebase, and there is no working-copy versus staged changes stuff, so there is less to learn ;-) Jan 18 16:26:53 :) Jan 18 17:45:35 hmm, looks like ubuntu-netbook is installable Jan 18 17:45:43 * ogra fires off an image build Jan 18 18:13:47 ogra: hm, no logs :-) Jan 18 18:13:57 even worse Jan 18 18:14:04 rsalveti, yeah, seems to always happen if a manually triggered build fails Jan 18 18:14:11 but i found our issue Jan 18 18:14:17 seb128 will solve it tomorrow Jan 18 18:14:23 ogra: what was it? Jan 18 18:14:28 rhythmbox is ftbfs Jan 18 18:14:38 and the old RB depends on the old webkit Jan 18 18:14:56 what was the status of banshee ? Jan 18 18:15:11 hm, ok Jan 18 18:15:18 maybe janimo knows better Jan 18 18:15:43 if it works we could just drop RB Jan 18 18:29:45 rsalveti, ogra, I am waiting for banshee 1.9.2 to be uploaded by mono team Jan 18 18:29:53 and see if the crash on startup appears Jan 18 18:29:53 k Jan 18 18:30:08 then we'll just wait another day for the rhythmbox fix Jan 18 18:30:20 I guess that neds to come anyway so I am not wokring on it , they had a maemo crash bugfix there, may be the same Jan 18 18:35:43 lool: which group should I add, ubuntu-core-dev or ubuntu-dev? Jan 18 18:36:44 janimo, yeah, i was only worried about our builds and was thinking of ripping out RB Jan 18 18:37:24 ogra, I thought I'd leave alone RB and other desktop apps while webkit and indicator transitions are being done Jan 18 18:37:35 after that settles it will probably nolonger be FTBFS on new uploads Jan 18 18:37:56 webkit is done, i was about to look at RB but seb128 seems to have a new upstream ready for tomorrow Jan 18 18:38:07 rsalveti: main > ubuntu-core-dev, universe > ubuntu-dev Jan 18 18:38:18 too bad LP cannot figure out to only start builds until build deps are satisfied (or maybe they are not stated strictly enough?) Jan 18 18:38:20 rsalveti: You don't necessarily need a team BTW Jan 18 18:38:22 so i was looking into the opportunity to drop RB and pull in banshee for today so we get images Jan 18 18:38:25 rsalveti: You could just rely on the UDD branches Jan 18 18:38:44 but it can wait another day i suppose Jan 18 18:38:44 ogra, I see. Jan 18 18:38:52 for the RB fix Jan 18 18:40:27 lool: well, I created a project for it, so a team sounds fine Jan 18 18:40:47 just to put the debian stuff into a proper bzr branch Jan 18 18:40:49 rsalveti: A project just for a packaging branch? Jan 18 18:40:56 rsalveti: a team is enough to hold it Jan 18 18:41:11 rsalveti: lp:~team-name/x-loader/ubuntu-packaging Jan 18 18:41:25 Usually ~ubutnu-core-dev or ~ubuntu-dev/x-loader/ubuntu Jan 18 18:41:46 Unless you created the x-loader project, which would be a good idea indeed Jan 18 18:42:02 lool: x-loader project Jan 18 18:42:23 I'm not in ubuntu-dev nor ubuntu-core-dev yet Jan 18 18:42:26 but working on it Jan 18 19:37:02 lool: at lp:x-loader you can find the latest branch for the debian package stuff Jan 18 19:37:19 lool: also released a new version, can you sponsor the update? Jan 18 19:37:29 otherwise I can just ask janimo or ogra :-) Jan 18 19:37:43 if you prefer I can also generate the debdiff Jan 18 19:47:31 lool, jcrigby: for those packages where we have the same person maintaining both the upstream linaro branch and the Ubuntu packaging, I've been favoring a git-buildpackage solution for now on the grounds that using bzr for packaging branches isn't going to make anything /easier/ than where we are now. But if you think there's a concern that other Ubuntu folks will be changing these packages, I'm equally happy to get jcrigby going with bzr Jan 18 19:49:40 Hello all! I'm a bit new to "embedded linux" so need some help. Going to migrate my GPS from WinCe to Linux 4 ARM CPU and is searching for some guide. or HowTo to figure out what I'll need and what the troubles may be. Can one send me a web link on the subj? Jan 18 20:29:06 kaim: good luck Jan 18 20:30:01 =) Jan 18 20:30:49 kaim: what you mainly need is a kernel for your device Jan 18 20:31:00 and a way to load it, of course(bootloader) Jan 18 20:31:49 As i do find for now ARM Linux has a support of my cpu Jan 18 20:32:05 but for the rest I have to examine the hardware first Jan 18 20:32:18 well, support for the cpu is easy to find Jan 18 20:32:22 but the device is what matters Jan 18 20:32:26 It seems like there is now distribution for handlets yet. Jan 18 20:32:28 and again, you need a bootloader first Jan 18 20:32:41 grub is not an option? Jan 18 20:33:05 it must be some port some wher Jan 18 20:33:08 were Jan 18 20:33:10 =( Jan 18 20:33:36 you could start playing with arm on linux on a device that's well supported already to get the ropes Jan 18 20:33:42 like a beagleboard Jan 18 20:34:10 otherwise you have to learn a lot at once, it may be rough times if there is no guide for your device! Jan 18 20:37:15 there isn't and thats why its an interesting one Jan 18 20:39:04 well sir, let me know when grub for arm is ready! Jan 18 20:40:21 jhobbs: I did hope there is one already =) Jan 18 20:40:32 i.e. GRUB Jan 18 20:43:55 slangasek: I understand; I personally pushed to be able to upload stuff when people were on leave and I had to get some stuff done; it could be that we can live with the owner of the Vcs then merging back later in these cases Jan 18 20:44:46 lool: right, though it does reintroduce the classical Debian NMU problem Jan 18 20:44:58 slangasek: Exactly Jan 18 23:09:13 Hi ubuntu-arm. I'm having a bit of trouble booting an Ubuntu image I created with rootstock Jan 18 23:09:41 on my Gumstix Overo OMAP3530. It may be the "sh -> dash" issue. Jan 18 23:11:44 Where does "dash" mess things up? Is it (1) on my host PC, (2) on the target FS created by rootfs, or (3) in the qemu image where rootfs runs? Jan 18 23:12:09 what actually happens? Jan 18 23:12:46 I boot up and it gets as far as Freeing init memory: 160K, then no more output. Jan 18 23:13:44 i doubt this is a dash/bash problem Jan 18 23:14:41 OK. I'll try a different kernel. Jan 18 23:17:53 EmbeddedLinuxGuy: Did you setup a serial console? Jan 18 23:18:33 Yeah I did --serial ttyS2 as per the Gumstix wiki Jan 18 23:18:34 EmbeddedLinuxGuy: dash shouldn't matter anyway, host PC or not Jan 18 23:18:53 EmbeddedLinuxGuy: Which kernel is this with? newer OMAP serials are ttyO2 and not ttyS2 IIUC Jan 18 23:19:13 OK some web page said this would cause it to halt and cause corruption. Jan 18 23:19:35 Hmm Andy just submitted a patch to linaro-image-tools to use ttyS2, maybe it's just ttyS2 for overo Jan 18 23:19:39 I was using the Angstrom 2.6.35 from November 15, but I am switching to a 2.6.34 Jan 18 23:20:16 Oh that would certainly use ttyS2 Jan 18 23:20:26 You need some initrd to go with it Jan 18 23:20:38 as to honor stuff like serialtty= and fixrtc on the cmdline Jan 18 23:23:05 OK. I was following a Wiki page that said: just put the kernel image, an MLO file, and a u-boot file on your first MicroSD partition Jan 18 23:23:16 and the root filesystem on the second partition. Jan 18 23:23:28 I assumed if there were an initrd it would be embedded in the kernel image. Jan 18 23:34:46 EmbeddedLinuxGuy: You need to have the proper cmdline arguments to match your kernel Jan 18 23:35:15 EmbeddedLinuxGuy: also, the rootfs might try to setup a tty of some sort as to allow you to login over serial; that's the goal of serialtty=, but that only work with an Ubuntu-ish initrd Jan 18 23:39:32 lool: Thanks, I have a feeling the kernel cmdline is being set by my u-boot.bin file. Jan 18 23:41:49 I have been trying to work from http://www.gumstix.net/wiki/index.php?title=Installing_Ubuntu_10.04_on_Gumstix_Overo but I am willing to try a different recipe Jan 18 23:42:20 EmbeddedLinuxGuy: When we have Linaro hwpacks (hopefully RSN now :-) I should have another one for you :-) Jan 18 23:56:33 rsalveti: i sponsored your x-loader and did some packaging cleanups Jan 18 23:56:46 rsalveti: You have a fair number of patches, are this reviewed by upstream? Jan 18 23:57:02 rsalveti: Also, I was wondering whether we need -fno-stack-protector both in a patch and in rules Jan 18 23:57:45 rsalveti: Ah I can't join yet Jan 18 23:57:48 s/jon/push Jan 18 23:59:29 rsalveti: Jan 18 23:59:35 https://code.launchpad.net/~lool/x-loader/packaging-fixes/+merge/46717 Jan 19 01:33:09 lool: patches are needed for panda and worked with TI Jan 19 01:33:22 and as I said I'm also working to push them upstream Jan 19 01:34:54 lool: and thanks for sponsoring it, will look at your merge request **** ENDING LOGGING AT Wed Jan 19 02:59:57 2011