[01:49]  * freeflying 
[01:49] <prpplague> ho ho hum
[01:51] <prpplague> anyone know what defconfig the canonical folks are using for their kernel?
[02:43] <eroick> hello, if i'm running 10.10 how can i use rootstock to build a rootfs of 10.04
[04:25] <rsalveti> prpplague: which kernel, omap4?
[04:51] <ogra_ac> hrm
[06:49] <Lellow> hello, i made a rootfs for arm using rootstock and I'm trying to run it in QEMU
[06:49] <Lellow> it boots but never gives me a console
[06:49] <Lellow> just stops after starting sshd and ntpd
[07:18] <rsalveti> sebjan: do you know if we have a working x-loader for blaze es2.1?
[07:19] <rsalveti> I'm basically using the same tree as panda, but compiled for sdp
[07:19] <rsalveti> for some reason it just reboots while starting the kernel boot
[07:20] <rsalveti> if I use the old x-loader vincent gave me (probably es1) it'll be even worse, rebooting at the time it tries to boot the kernel
[07:20] <rsalveti> without giving any message, even with earlyprintk
[07:20] <rsalveti> u-boot should be fine, I'm using linaro's one that's based upstream
[07:21] <rsalveti> it could be that we need a fix in the kernel, but I don't even know now if the x-loader is correct
[08:07] <sebjan> rsalveti: hi!
[08:09] <sebjan> rsalveti: for blaze bootloaders: I have some, but they are based on different baselines than yours.
[08:10] <sebjan> rsalveti: regarding u-boot, this may be the biggest issue: blaze is not supported by Linaro u-boot, and the pinmux is made into the Linaro u-boot...
[08:16] <hrw> morning
[08:43] <hrw> JamieBen1ett: hi, did you got touchpad working under maverick?
[08:43] <JamieBen1ett> hrw: no, its on my list of things to do today. Seems after an apt-get upgrade my wifi has stopped working so now I need to use a wired connection :(
[08:48] <hrw> JamieBennett: impressive list of failures
[08:48] <JamieBennett> hrw: right, I'm tempted at a full reinstall as others have reported it working
[08:49] <JamieBennett> hrw: don't have a lot of time to be investigating it ATM
[08:49] <hrw> heh... I love that m$ way of thinking..
[08:49] <JamieBennett> hrw: heh true
[08:50] <hrw> my Debian rootfs had 6-7 years when I did reinstall just due to x86 ->x86-64 change
[08:50] <JamieBennett> hrw: impressive
[08:51] <hrw> on 6 Nov 2006 I moved to amd64 so Debian rootfs will have 4 years soon
[08:51] <hrw> but I do not use it since @canonical
[14:55] <rsalveti> sebjan: cool, thanks for the email, just replied
[15:22] <sebjan> rsalveti: I am preparing a detailed answer, will be ready soon!
[15:22] <mopdenacker> f**k, Maverick's Initrd's are compressed by lzma on ARM. I didn't expect this. Is this the same on x86?
[15:22] <ogra_ac> mopdenacker, yes, everywhere
[15:23] <mopdenacker> It took me a while to figure out. Had to read the magic number to find this.
[15:23] <ogra_ac> lzcat <initrd_file | gzip > initrd_new
[15:23] <ogra_ac> easily converted
[15:24]  * ogra_ac haeds over to the office
[15:25] <mopdenacker> Hi ogra_ac ! Thanks! LZMA is much slower to decompress... doesn't it slow down the boot process for machines with fast I/O? On OMAP, I can imagine you boot faster because of the slower I/O (MMC for example)
[15:28] <mopdenacker> Here are the commands to extract the contents of a uInitrd file: dd if=uInitrd of=initrd.cpio.lzma skip=64 bs=1; lzcat initrd.cpio.lzma | cpio -id
[15:49] <rsalveti> sebjan: cool, thanks
[16:26] <rsalveti> sebjan: oh, huge capacitor
[16:26] <rsalveti> we're just removing it
[16:36] <ndec> ogra_ac: hi! how's dallas!
[16:37] <ogra_ac> warm :)
[16:38] <ndec> ogra_ac: question: when is the boot.scr file generated after the partition resize on first boot? is it done in initrd or in real FS?
[16:40] <GrueMaster> ndec: It is done by jasper in intrd after resize.  After that, it comes from /boot/boot.script and is copied to the boot partition by flash-kernel.
[16:43] <rsalveti> sebjan: do you know any other difference between sdp and blaze?
[16:43] <ndec> rsalveti: blaze looks nicer...
[16:43] <rsalveti> haha, for sure
[16:47] <ndec> GrueMaster: thx.
[16:47] <ndec> GrueMaster: by the way, in the daily image the initrd image is not installed in /boot. is that normal?
[16:48] <ndec> GrueMaster: does the initial initrd (e.g. the one in the image) have any differences from the next initrd images that are generated upon kernel upgrade?
[16:50] <rsalveti> ndec: sebjan: mopdenacker: hey, blaze es2.1 up and running
[16:50] <rsalveti> after we removed the capacitor it just boots fine
[16:50] <sebjan> rsalveti: cool! :)
[16:50] <rsalveti> with linaro's u-boot and x-loader from my tree
[16:50] <sebjan> wow
[16:50] <rsalveti> and our kernel, without any other change
[16:51] <GrueMaster> ndec: Not sure what you are seeing, but on my system with 20101006 + latest kernel, I have /boot/initrd.img -> initrd.img-2.6.35-903-omap4
[16:52] <mopdenacker> rsalveti: Yesssss!
[16:52] <rsalveti> robclark: 864x480
[16:52] <robclark> yup, that sounds right
[17:02] <mopdenacker> GrueMaster: One question related to ndec's question. On Blaze, boot.scr gets created with the wrong 'root=' setting. It seems that the 'root' variable if still set to /dev/mmcblk0p2 in the initramfs (scripts/local-bottom/jasper_setup)
[17:02] <mopdenacker> GrueMaster: do you know where this root variable is defined? Is supposed to have the same value as the 'root' kernel parameter?
[17:04] <GrueMaster> Is this a fresh image?  jasper is supposed to change it to match the uuid of the boot partition, whis won't matter what drive type or location.
[17:04] <GrueMaster> which
[17:04] <ndec> GrueMaster: but do you have the file initrd.img-2.6.35-903-omap4? i am seeing a broken link, not actual file
[17:04] <GrueMaster> Yes
[17:05] <GrueMaster> Have you run oem-config successfully?  One of the last steps is that it runs some of the kernel post-install scripts (one of which generates the initrd.img file).
[17:05] <GrueMaster> It does this so that it can remove jasper.
[17:06] <ndec> oh. i see... i was looking at FS before doing the install
[17:07] <GrueMaster> There are a lot of things that get done on first boot that help to keep the image small for downloading.  Normal images wouldn't have these issues, but preinstalled images are a different animal.
[17:22] <mopdenacker> GrueMaster: I was talking about the initial uInitrd found in preinstalled images (downloaded a fresh one this morning).
[17:22] <GrueMaster> That is built during image build time and is not part of the image.
[17:23] <GrueMaster> At least the initrd.img isn't.
[17:23] <mopdenacker> GrueMaster: do you know where jasper sets this 'root' variable?
[17:23] <GrueMaster> I'd have to look at the jasper source.  Give me  a moment.
[17:26] <GrueMaster> Looking at the source, it pulls this from /proc/cmdline
[17:27] <GrueMaster> So the initial boot.scr (created during image creation) is where it is initially set.  After jasper resizes the rootfs, it uses the UUID.
[17:27] <mopdenacker> GrueMaster: ahah, very interesting!
[17:28] <mopdenacker> GrueMaster: So, on the Blaze, even if we don't use the boot.scr file, it is still used as input.
[17:28] <mopdenacker> That's something we can fix then.
[17:29] <mopdenacker> GrueMaster: would you be so kind to tell me in which file you've read this, please?
[17:30] <GrueMaster> What do you need to fix?  We have blaze working here with an updated MLO and u-boot.bin on the standard image.
[17:30] <GrueMaster> Using our boot.scr
[17:31] <ndec> GrueMaster: ? you at least had to manually change the initial boot.scr to set mmcblk1p2, no?
[17:31] <ndec> GrueMaster: on blaze the SD card is on mmcblk1, not mmcblk0.
[17:32] <GrueMaster> Oh.  yes.  THe image that we booted had already run jasper.
[17:33] <ndec> GrueMaster: ok. so we are trying to run the image before jasper. e.g.  do the resize and install on blaze.
[17:34] <ndec> so we change the initial boot.scr with /dev/mmcblk1p2, install goes fine. but at the end the new boot.scr is generated with wrong label.
[17:34] <GrueMaster> According to rsalveti, all you need to do is change the MLO, u-boot.bin, and modify the root= line in the boot.scr.
[17:34] <mopdenacker> ndec: I didn't touch boot.src
[17:35] <mopdenacker> ndec: I just booted "manually", typing the commands in boot.scr, but didn't touch this file.
[17:35] <mopdenacker> ndec: let me check that this works.
[17:35] <ndec> mopdenacker: ok. but what is your value for root?
[17:35] <ndec> mopdenacker: settings bootargs or reading the boot.scr is the same, if you use the same values. the boot.scr is not read by jasper.
[17:36] <ndec> GrueMaster: i agree with this. but mopdenacker tried and it didn't work... but given what's just ^^^ that might be an issue on our end..
[17:36] <mopdenacker> ndec: root=/dev/mmcblk1p2 in the bootargs, but I left boot.scr with "root=/dev/mmcblk0p2" (didn't touch this file, since it wasn't used)
[17:37] <mopdenacker> Or so I thought
[17:38] <ndec> GrueMaster: rsalveti: i have to go now... but I will come back later in the evening. in the mean time if you could try to run the install on blaze and check the partition label, and verify flash-kernel.conf, that would be nice.
[17:39] <GrueMaster> I'll check it as soon as Ican pry it away from rsalveti.  :P
[17:43]  * rsalveti reading
[17:46] <rsalveti> yep, will try now :-)
[17:47] <rsalveti> yee, second blaze display working!
[17:47] <rsalveti> with help from vincent-laptop :-)
[17:48] <mopdenacker> rsalveti: nice to be working at the same place. I hope you will have opportunities to come to TI in Nice :-)
[17:49] <rsalveti> mopdenacker: yeah, that'd be cool :-)
[17:51] <mopdenacker> GrueMaster: nah, didn't work. Even with a correct boot.src and root= boot parameter (/dev/mmcblk1p2), I still end up with root=LABEL=emmcroot in boot.scr after reboot.
[17:52] <orbarron> hey all --> how do I switch form netbook version to desktop version? (not from GUI)
[17:52] <mopdenacker> It took the label from /dev/mmcblk0p2, instead of using the one from /dev/mmcblk1p2 (the SD card). There's a bug somewhere, though I don't see where...
[17:52] <GrueMaster> mopdenacker: checking...
[17:53] <rsalveti> mopdenacker: I'm trying right now with a new image
[17:54] <mopdenacker> GrueMaster: rsalveti : thanks! Gotta go. Good luck! Keep us posted!
[17:54] <rsalveti> mopdenacker: sure, see ya
[18:06] <robclark> orbarron: /etc/gdm/custom.conf
[18:06] <robclark> (or do it from gui)
[18:07] <robclark> or if you disable automatic login, you can choose on each login which session you want
[18:08] <orbarron> ahh thanks robclark
[18:46] <dhiry2k> getting error in installing xfce4 or lxde as no such package
[18:46] <dhiry2k> apt-get update working fine
[18:47] <dhiry2k> apt-cache search also not showing package entry
[18:47] <dhiry2k> what repository need to be add for marvick arm
[18:47] <dhiry2k> to get these packages
[18:51] <dhiry2k> any one can help me to get install lxde in arm
[19:03] <rsalveti> jo-erlend_igep: you're luck, both network and display patches got applied
[19:19] <ogra> mopdenacker, so here is the code snippet caring for setting the UUID http://paste.ubuntu.com/508141/
[19:19] <ogra> mopdenacker, i dont see how it could possibly be worng
[19:23] <devilhorns> ogra, while your here, quick question ... is zeitgeist a "must have" ? or can I implement the searching in a different way ?
[19:23] <ogra> devilhorns, i think ts a requirement , how else would you implement it ?
[19:24] <devilhorns> ogra, not sure yet :) but I noticed that zeitgeist is python based, so I want to implement searching in a different way so it isn't slow
[19:24] <ogra> (teh zeitgeist packages are properly maintained already, if another solution adds extra maintenance work we wont be able to use it)
[19:27] <devilhorns> ogra, I haven't really thought much about a replacement yet, but was just curious if I "can" replace it :)
[19:28] <cooloney> mpoirier, hey man
[19:28] <cooloney> mpoirier, i saw your git pull request about ftrace, that's good, why not for ti-omap4 tree or master only linaro?
[19:30] <ogra> devilhorns, with something thats maintained by the ubuntu-desktop team and that offers the same functionallity you can
[19:30] <devilhorns> ogra, gotcha
[19:30] <devilhorns> thanks
[19:31] <ogra> (i doubt you will find such a thing, good luck :))
[19:31] <devilhorns> hehehe
[20:02] <mpoirier> cooloney: sorry I missed you post - I stepped out for lunch.
[20:03] <cooloney> mpoirier, np, man. i saw your ftrace git pull request
[20:03] <mpoirier> cooloney: Tim ask me to check it in to linaro first.  Also, I haven't tested for omap4 - it should work but I won't submit something I haven't tested.
[20:03] <cooloney> mpoirier, ok, gotcha
[20:04] <cooloney> mpoirier, i will try to rebase you patch on our current omap4 tree
[20:04] <mpoirier> cooloney:  fantastic but make sure you test - again, I haven't tried on omap4.
[20:05] <mopdenacker> ogra: thanks! That's the code we've been looking at too. The only thing that could be wrong is the value of the 'root' variable.
[20:05] <cooloney> mpoirier, yeah, sure. i will test. so how did you test it?
[20:05] <cooloney> on omap3?
[20:05] <mpoirier> omap3 yes.
[20:05] <ogra> mopdenacker, right and thats handed over by the kernel to the environemnt
[20:05] <mpoirier> I simply enabled the feature and tested a function.
[20:05] <cooloney> mpoirier, good, understand
[20:06] <mpoirier> there is another set of patches to enable graph testing but that will be harder to put in.
[20:07] <mpoirier> the patches don't apply properly *and* it is deep in assembler macros and obscure symbols...
[20:09] <cooloney> mpoirier, yeah, i tried that before.
[20:09] <cooloney> mpoirier, painful
[20:09] <mpoirier> the graph tracing patch set ?
[20:10] <rsalveti> mopdenacker: I'm just debugging it, doesn't work here because for some weird reason root must be wrong and then we hang at grep
[20:10] <rsalveti> and I can't run the first boot
[20:12] <mopdenacker> ogra: interesting. I didn't know that the kernel was passing environment variables to the init process (did I get it right?)
[20:12] <cooloney> mpoirier, not try to test, but just apply with dynamic ftrace together
[20:12] <cooloney> many conflict
[20:12] <cooloney> but maybe it changes
[20:12] <mopdenacker> rsalveti: weird indeed.... Good luck!
[20:13] <mpoirier> cooloney: your are right, the first patch set for dynamic tracer weren't applying properly.
[20:14] <mpoirier> cooloney: I was able to apply the first patch set after a lot of work.
[20:14] <cooloney> mpoirier, yeah, ftrace is quite important. thx for your work
[20:14] <mpoirier> but the final submission by Rabin (the author) applied seamlessly.
[20:14] <cooloney> mpoirier, so how about the upstream status of this dynamic ftrace patchset
[20:15] <cooloney> mpoirier, cool
[20:15] <ogra> mopdenacker, well, the kernel is *supposed* to hand over the whole cmdline to init ... probably it doesnt
[20:15] <mpoirier> cooloney: it has been accepted.
[20:15] <cooloney> mpoirier, it's in rmk's upstream or mainline?
[20:15] <mpoirier> cooloney: now I have to get graph tracing in.  I'll need help from the implementor - I have to hunt him down.
[20:16] <cooloney> mpoirier, great, author always helped a lot
[20:16] <mopdenacker> ogra: so each kernel parameter becomes an environment variable?
[20:16] <mpoirier> cooloney: http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=shortlog;h=80be7a7f642719bf99fc49692fc77d6333f51a73
[20:18] <ogra> mopdenacker, each one that has an equal sign
[20:18] <mopdenacker> mopdenacker: very very cool! :-)
[20:20] <ogra> bug 586386
[20:20] <ubot2> Launchpad bug 586386 in linux (Ubuntu Maverick) (and 1 other project) "omap3 kernel should hand over all comdline args to the init environment (affects: 1) (heat: 27)" [Medium,Fix released] https://launchpad.net/bugs/586386
[20:20] <ogra> gah
[20:21] <GrueMaster> rsalveti: dd if=uInitrd of=initrd.cpio.lzma skip=64 bs=1; lzcat initrd.cpio.lzma | cpio -id
[21:11] <cooloney> robclark, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
[21:11] <ndec> GrueMaster: rsalveti: ogra: hi. i am back. did you try booting the pre installed image on blaze?
[21:11] <GrueMaster> Working on it now.  Looks like a kernel bug.
[21:14] <ndec> GrueMaster: root is not propagated in init properly?
[21:14] <GrueMaster> Just found out it is a kernel config option that was missed.
[21:20] <ogra> ndec, right, as GrueMaster aid
[21:20] <ogra> *said
[21:20] <ndec> GrueMaster: which one?
[21:21] <ndec> this is a bummer...
[21:21] <ogra> ndec, seems on a rebase the fix for bug 586386 got lost
[21:21] <ubot2> Launchpad bug 586386 in linux (Ubuntu Maverick) (and 1 other project) "omap3 kernel should hand over all comdline args to the init environment (affects: 1) (heat: 27)" [Medium,Fix released] https://launchpad.net/bugs/586386
[21:21] <ogra> ndec, its not as bad as it looks though, we'll just offer a fixed uImage to put in place on first boot
[21:22] <ogra> we're just testing the fix
[21:22] <ndec> we can't upload the fix?
[21:22] <ogra> we can, but only as SRU
[21:22] <ogra> bad timing to find it
[21:30] <ndec> ogra: yep. sorry about that.
[21:31] <ogra> ndec, ??
[21:31] <ndec> ogra: i wish we found this earlier ;-(
[21:31] <ogra> ndec, our kernel team screwed it up
[21:32] <ogra> its good that yo found it at all, there are other bits relying on the feature
[21:33] <cooloney> that option was enabled in our master branch to support this feature for omap3
[21:33] <cooloney> need to carry it to our ti-omap4 as well
[21:38] <rsalveti> cooloney: still building the kernel?
[21:39] <rsalveti> mopdenacker: I found one bug here, so we're going to also need a new uImage together with MLO and u-boot
[21:39] <rsalveti> but then we can successfully boot blaze
[21:39] <rsalveti> and the installer should just work fine :-)
[21:45] <ndec> rsalveti: and new boot.scr, since it needs to have mmcblk1p2
[21:45] <rsalveti> ndec: yeah, right
[21:48] <rsalveti> ndec: vincent-laptop: and about wifi and bt modules, should it work the same way as panda?
[21:49] <ndec> rsalveti: well... no!
[21:49] <rsalveti> sorry, don't know much about blaze hardware
[21:49] <ndec> blaze has a different wlan chip (1283) instead of 1271
[21:50] <ndec> we don't have an up-to-date driver for 1283. but we are trying to get it.
[21:50] <rsalveti> ndec: ok then, less things to check :-)
[21:50] <ndec> rsalveti: well you can play with xorg.conf and create 2 desktops ;-) we tried this already!
[21:51] <rsalveti> ndec: yeah, just enabled the second framebuffer, but didn't change X to use both screens
[21:51] <ndec> there is an accelerometer and proximity sensor on blaze. i think drivers should be there. never tested.
[21:51] <rsalveti> had to check the installer problem
[21:52] <rsalveti> ndec: do you have the xorg.conf already around?
[21:52] <ndec> what would be nice is virtual desktop supporting both screens so that we can move windows from top to bottom screen... and also support for multiple touchscreen
[21:52] <ndec> yes, let me find it
[21:52] <rsalveti> yeah
[21:54] <ndec> rsalveti: http://paste.ubuntu.com/508281/
[21:55] <rsalveti> ndec: cool, thanks a lot
[21:55] <rsalveti> will try in a bit
[21:56] <prpplague> cooloney: hey you got that card ready?
[21:56] <ndec> rsalveti: since we are talking about blaze and x11... blaze has a custom keypad. we probably need to create a new kbd layout for it. for now we have a quick hack and we create /etc/X11/Xmodmap. but that breaks panda ;-)
[21:56] <ndec> rsalveti: what do you recommend to handle the blaze keypad?
[21:57] <cooloney> prpplague, got some issue after upgrading, please wait for a while. sorry
[21:57] <prpplague> cooloney: doh
[21:58] <prpplague> cooloney: runnign out of time for today
[21:59] <cooloney> prpplague, i tried to dd out my 4G rootfs to a image file, and dd to your card. but cannot boot my panda
[21:59] <prpplague> cooloney: don't have a tar ball of the rootfs i can use?
[22:00] <cooloney> prpplague, so i am copying over our daily image to your SD card, and have to install it on the board.
[22:00] <ndec> rsalveti: GrueMaster: ogra: I am trying to create pre installed image where our package (which are in OMAP PPA) are also pre installed. So basically we download cdimage, chroot in rootFS and install all our stuff. but do you think we can install new kernel as well? I am not sure if that should/would break the installer.
[22:00] <rsalveti> ndec: don't know the right answer now, but probably creating a new key layout for it
[22:00] <rsalveti> then we can identify if we're running blaze and load the correct kbd layout
[22:00] <ndec> ogra: ^^^^ about the blaze keypad, in case you have an idea.
[22:00] <ogra> ndec, you should be able to do it chrooted in the SD, it gets tricky if you loop mount
[22:01] <ogra> (replacing the kernel)
[22:01] <ndec> rsalveti: if you boot on blaze, and look at the X11 log, you will see that the keypad is detected (omap4-keypad). so it's probably just missing a config to load the proper keymap, right?
[22:01] <cooloney> prpplague, i don't have the tar rootfs. and if is the ubuntu minimal rootfs from rootstock, we need to install extra applications.
[22:02] <cooloney> prpplague, so if got the daily image installed properly, please keep the SD for development and testing
[22:02] <rsalveti> ndec: probably
[22:02] <ndec> ogra: in fact I had to loop mount the ext3 and fat32 as well. I created a fake flash-kernel.conf so that flash kernel would flash inside the .img. it seemed to work.. but I wanted to hear from you what you think.
[22:02] <rsalveti> ndec: you can update the kernel, but just make sure you also generate a new uinitrd
[22:02] <rsalveti> because of the proper kernel modules, if you're changing versions
[22:03] <cooloney> prpplague, actually i tried to tar out the rootfs tar ball, it is quite slow for me
[22:03] <ndec> yes, otherwise modules aren't found in initrd. we had this the first time ;-)
[22:03] <ndec> in fact it seems we were able to even flash the new uImage and uInitrd in the .img using flash-kernel ;-)
[22:04] <rsalveti> ndec: yep
[22:04] <rsalveti> the problem you can easily find on the pre-installed image is lack of inodes and space
[22:04] <rsalveti> because you still didn't run the resize
[22:04] <rsalveti> so you're kind of limited in what you can install and edit before running the first boot
[22:08] <prpplague> rsalveti: guys i'm dying here, has _anyone_ got an ubuntu file system i can use?
[22:09] <rsalveti> prpplague: sure, I have a valid sd card here for panda
[22:09] <cooloney> prpplague, i'm installing the daily image on your SD, just a minutes
[22:10] <ndec> rsalveti: well... i forgot to mention that we resize it first... well in fact everything is here: http://omappedia.org/wiki/Add_Packages_To_Ubuntu_Preinstalled_Images
[22:12] <prpplague> cooloney: ahh ok
[22:15] <rsalveti> ndec: oh, ok
[22:15] <rsalveti> ndec: so you're fine
[22:16] <ogra> ndec, with fake flash-kernel i see no prob
[22:16] <ogra> just make sure to remove it again ;)
[22:16] <ndec> ogra: well, we forgot the first time ;-)
[22:16] <rsalveti> cooloney: OK, I can confirm that jasper works with this kernel fix
[22:17] <cooloney> rsalveti, thx, man
[22:17] <ndec> rsalveti: cool! is it cross compiled or native?
[22:17] <cooloney> ndec, my testing kernel is cross compiled
[22:17] <ndec> given that it only took a few minutes I think I know the answer
[22:17] <cooloney> rsalveti, just tested that
[22:18] <ndec> cooloney: can you post a native kernel somewhere later in the day?
[22:18] <cooloney> native building kernel?
[22:18] <cooloney> i will try to build it in our schroot environment
[22:21] <rsalveti> ndec: I'm just publishing all the needed files for blaze to work
[22:21] <rsalveti> with the pre-installed image
[22:21] <rsalveti> so GrueMaster can actually test it
[22:21] <rsalveti> hold a sec
[22:33] <rsalveti> ndec: GrueMaster: http://people.canonical.com/~rsalveti/maverick/blaze/
[22:33] <ndec> rsalveti: cool! will test tomorrow... no blaze at home ;-)
[22:34] <rsalveti> that should be enough to get blaze up and running with the installer
[22:34] <ndec> uboot is based of linaro uboot, right? not mainline, nor TI uboot?
[22:38] <rsalveti> ndec: based on linaro, but very very close with upstream
[22:39] <rsalveti> the only missing part now is the new mmc driver
[22:39] <rsalveti> but doesn't affect us
[22:39] <ndec> rsalveti: can you send your patch to me and sebjan?
[22:39] <rsalveti> ndec: what patch?
[22:39] <rsalveti> :-)
[22:40] <ndec> rsalveti: what? uboot linaro works out of the box?
[22:40] <rsalveti> the x-loader is my tree on gitorious and linaro is basically from git.linaro.com
[22:40] <rsalveti> ndec: yup
[22:40] <rsalveti> I just had to build it for omap4430sdp
[22:40] <ndec> rsalveti: well this is a surprise... so sometimes things work out of the box ...
[22:40] <rsalveti> will fill a bug for this on launchpad soon
[22:41] <rsalveti> ndec: it's basically because it's quite simliar with upstream
[22:41] <rsalveti> so it shouldn't be an issue
[22:41] <ndec> i am sure ogra which tablet would work out of the box too ;-)
[22:41] <rsalveti> but it'd be good if we could check the padmux setting
[22:41] <rsalveti> because I know sakoman did change the padmux for panda and not for blaze
[22:41] <rsalveti> don't where he got the values for blaze
[22:42] <rsalveti> ndec: probably, would be good to test
[22:42] <ogra> ndec, well, i cant even build the kernel ... the display driver seems to dep on some headers i miss
[22:42] <ndec> rsalveti: you might know this already, but our TI uboot based on upstream too is here: http://dev.omapzoom.org/?p=bootloader/u-boot.git;a=shortlog;h=refs/heads/omap_upstream
[22:42] <ndec> ogra: hehe I had told you ;-)
[22:43] <ogra> it builds if i disable all omap2 dss drivers thogh
[22:43] <ogra> not sure how useful that still is :)
[22:44] <sakoman> ndec: I don't recommend using that omapzoom u-boot branch
[22:44] <sakoman> it is already obsolete
[22:44] <rsalveti> yeah
[22:44] <ndec> ogra: it's useful for blaze. even though it's called omap2, it means everything after omap2.
[22:44] <rsalveti> sakoman: did you also review the sdp pad mux?
[22:44] <ndec> sakoman: euh? isn't that the tree TI uses for its release?
[22:45] <ogra> ndec, yeah, i guessed so much
[22:45] <sakoman> ndec, perhaps it is, but that doesn't mean it is the latest and best ;-)
[22:45] <ndec> sakoman: in fact it probably means, it's not !
[22:45] <rsalveti> ndec: sebjan said TI tested blaze with upstream u-boot
[22:45] <sakoman> rsalveti: I'll take a look at the sdp pinmux and see if anything needs to be changed
[22:46] <rsalveti> sakoman: cool, thanks a LOT :-)
[22:46] <rsalveti> need to buy you some beers
[22:46] <sakoman> rsalveti: last time I checked it was ok, but perhaps new issues have been found
[22:46] <rsalveti> because then we can just use upstream (and linaro) for all omap4 boards
[22:46] <rsalveti> even omap3
[22:46] <ndec> sakoman: the problem is that TI developers will continue to push into dev.omapzoom.org...
[22:46] <sakoman> rsalveti: I am working hard to make that possible
[22:47] <rsalveti> yeah, I know :-)
[22:47] <ndec> sakoman: you looking at tablet too?
[22:47] <sakoman> rsalveti: I will have relocation patches for mainline panda and sdp in a day or two
[22:48] <sakoman> ndec: I only work on hardware that I have :-)
[22:48] <rsalveti> sakoman: cool
[22:48] <sakoman> rsalveti: panda works fine, but sdp still has issues
[22:48] <ndec> sakoman: that's safer
[22:48] <rsalveti> sakoman: what issues are you currently having at sdp?
[22:49] <sakoman> the version with relocation takes a fault after printing the ram size
[22:49] <rsalveti> oh, ok
[22:49] <sakoman> in the middle of tracking down the problem
[22:49] <rsalveti> sakoman: but do you know any issue with current tree?
[22:50] <sakoman> no issues with the released v2010.09 as far as I know
[22:50] <sakoman> only with top of tree post the forced change to relocation
[22:50] <rsalveti> awesome, maybe still some wrong pad mux setting, but here it seems to be running fine
[22:50] <sakoman> but then pretty much all arm boards other than beagle and overo are broken :-)
[22:50] <rsalveti> but didn't test bt and wlan
[22:50] <rsalveti> lack of drivers
[22:50] <rsalveti> :-)
[22:51] <sakoman> and soon panda and sdp4430
[22:51] <sakoman> the current version of the patch is in my omap4-exp branch
[22:52] <sakoman> about a dozen or so of those patches should hit mainline in the next week
[22:53] <rsalveti> nice, too bad I don't have a blaze to test :-(
[22:53] <rsalveti> I just got one here because I'm currently at TI
[22:53] <sakoman> my blaze has ES1.0 processor :-(
[22:54] <sakoman> and my panda an already obsolete ES2.0
[22:54] <ndec> rsalveti: you can get a blaze: http://svtronics.com/market_omap ;-)
[22:55] <GrueMaster> sakoman: ES2.0 8L should still work with the release image.
[22:55] <rsalveti> ndec: hahaha :-)
[22:55] <rsalveti> wayyy too expensive
[22:56] <sakoman> GrueMaster: that doesn't help me doing x-load and u-boot patches for ES2.1 changes :-)
[22:56] <GrueMaster> No, but you can build them on your 2.0.  :P
[23:34] <ogra> lool, do you know why i cant find any vfp stuff in the -dumpspecs gcc comand ?
[23:34] <ogra> i though we enabled it by default ages ago
[23:37] <ndec> ogra: sometimes when installing a package, it triggers a 'system restart required' event. how can i make a package that does this?
[23:38] <ogra> you dump something into a dir (i have to check the exact path)
[23:39] <ogra> ndec, touch /var/run/reboot-required i think
[23:43] <ndec> ogra; well it worked on my laptop... so I just need to do this in postinst script.
[23:47] <cooloney> ndec, the patched native built kernel is here http://people.canonical.com/~roc/kernel/pass_init/linux-image-2.6.35-903-omap4_2.6.35-903.14_armel.deb
[23:47] <cooloney> ndec, http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
[23:47] <ndec> cooloney: thx. how do you build native kernel? qemu or on real hw?
[23:47] <cooloney> ndec, also i pushed the patch in my branch.
[23:48] <ndec> cooloney: i saw your SRU email too
[23:48] <cooloney> ndec, we setup schroot environment in our built server
[23:48] <cooloney> so i schroot to maverick-armel to do native building
[23:48] <ndec> but on hw, not qemu?
[23:54] <cooloney> oh, it is on a x86 server's schroot environment.
[23:54] <cooloney> ndec, it looks like it doesn't use qemu to me
[23:58] <lool> ogra: arm-linux-gnueabi-gcc -v 2>&1|grep vfp