[00:06] <NCommander> eggonlea: ping?
[00:07] <NCommander> eggonlea: if your around, I'd like to poke your brain on Dove stuff
[00:07] <crimsun> does anything else need to be done for bug 528524? I'm pretty short on time, and it's pretty clear that it isn't a PA bug or a linux bug.
[00:07] <ubot4> Launchpad bug 528524 in speex (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps on dove (affects: 3)" [High,Confirmed] https://launchpad.net/bugs/528524
[00:08] <NCommander> crimsun: it still doesn't work with that change, that just fixes the issue Li Li brought up
[00:08] <crimsun> NCommander: *what* doesn't work?
[00:08] <NCommander> crimsun: audio through pulse
[00:08] <NCommander> or at lesat, I couldn't get it to work
[00:09] <crimsun> what are your test cases, or are you saying that generally audio just doesn't work through PA?
[00:09] <NCommander> thats exactly what I'm saying
[00:10] <crimsun> ...so, the latteR?
[00:10] <NCommander> crimsun: I haven't played a lot with it today, GrueMaster knows more about this than I do
[00:10] <NCommander> crimsun: oh, wow, I'm braindead >.>;
[00:11]  * NCommander goes to grab dinner
[01:30]  * NCommander returns
[02:24] <eggonlea> NCommander: yes
[02:25] <NCommander> eggonlea: mind if I PM you?
[02:25] <eggonlea> NCommander: I'm updating all components on new Lucid with the latest kernel.
[02:26] <eggonlea> NCommander: welcome~ :P
[02:26] <NCommander> eggonlea: handy, I'd like to work with you on determining if the reason I can't get the codecs to work is just me being infamiliar with gstreamer
[02:26] <eggonlea> NCommander: which kernel are you using? I think Eric is merging the new LSP today.
[02:27] <NCommander> eggonlea: archive latest, but I also tried the BSP on the wiki
[02:27] <eggonlea> NCommander: OK, please feel free to let me know if I can do anything.
[02:28] <NCommander> eggonlea: I'd like to see if we can get accelerated playback to work, also, if possible, I'd like to get the EXA modules
[02:30] <eggonlea> I'll upload them today
[04:21] <GrueMaster> crimsun: I updated bug 528524 with more information.  The speex patch only enables armv7 stuff, which wasn't the issue.  The test that I ran was speaker-test -c 2 -t pink -f 44100 -r 44100.  Adding the user to the pulse group, deleting ~/.pulse/* , or killing pulseaudio altogether are the only ways for this command to work (even with the speex fix).
[04:21] <ubot4> Launchpad bug 528524 in speex (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps on dove (affects: 3)" [High,Confirmed] https://launchpad.net/bugs/528524
[04:47] <ericm_> GrueMaster, so I really suspect it's a permission issue
[05:14] <DanaG> GrueMaster: is the thing headless?
[05:14] <DanaG> If so, consolekit / policykit may be blocking access to the audio device.
[05:15] <DanaG> rcn-ee: did you check out the suspend/resume stuff?
[06:59] <GrueMaster> DanaG: No, it isn't headless.
[06:59] <DanaG> hmm, are policykit and consolekit installed?
[07:00] <DanaG> If not, try installing them.
[07:03] <samuel_Sayag> Is there doc about installing xfce on Beagle ?
[07:18] <rsalveti> nosse1: was finally able to test the user mode emulation here with the lucid rootfs
[07:19] <rsalveti> nosse1: please check at the end of https://wiki.ubuntu.com/ARM/RootfsFromScratch
[07:20] <rsalveti> nosse1: in case you're running ubuntu, you just need to install qemu-arm-static, and the package will register itself at the binfmt
[07:20] <rsalveti> if you're not using ubuntu, just make sure you have the latest qemu-arm-static binary at your system and register it at your binfmt
[07:21] <rsalveti> to register it, run # echo ':qemu-arm-static:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:' > /proc/sys/fs/binfmt_misc/register
[07:22] <rsalveti> nosse1: then once you're inside the chroot environment, you can use it to build and test your arm packages/applications
[07:23] <rsalveti> time to get some sleep :-)
[07:31] <NCommander> GrueMaster: using pavucontrol, I was able to move the audio output on Pulse
[07:35] <GrueMaster> Do you already have the changes in /usr/share/pulseaudio/alsa-mixer/paths/?
[07:36] <GrueMaster> Because pavucontrol and sound-applet->preferences have the exact same layout.
[07:36] <GrueMaster> NCommander: ^^^
[07:39] <NCommander> GrueMaster: if they were pushed in archivem, then yes
[07:40] <GrueMaster> Then that's how you can get pavucontrol to work.  Both it and gnome-sound-applet are front ends to pulseaudio.  You can even use pacmd to change the settings.
[07:40] <NCommander> GrueMaster: oh, ok
[07:40]  * NCommander feels dense
[07:41] <GrueMaster> Get some sleep.  It helps.
[07:46] <NCommander> GrueMaster: not tired :-/
[07:46] <NCommander> eggonlea: ping?
[08:15] <nosse1> Good morning everyone
[08:42] <eggonlea> NCommander: ack. You should go to bed indeed.
[08:44] <NCommander> eggonlea: probably, but your still here so :-)
[08:46] <eggonlea> Hey, I'm in GMT+8 but you NOT!
[08:53] <ericm_> eggonlea, NCommander is a superman
[08:55] <eggonlea> ericm_, Agree! any luck on the new kernel?
[08:55] <ericm_> eggonlea, I've filed a difference to you, you check and let me know if everything is OK before I merge
[08:58] <eggonlea> ericm_, checking...
[09:29] <eggonlea> ericm, It's fine. Let's move on. :)
[09:37] <samuel_Sayag> I can't make the keyboard work with  Karmic installation
[10:09] <hrw> morning
[10:09] <kapu> hi morning
[10:11] <hrw> rsalveti: u8500? where you are working?
[10:12] <nosse1> What's the best approach for stracing upstart? Because upstart needs to be process no. 1, right?
[10:16] <hrw> nosse1: "init=strace upstart"?
[10:49] <nosse1> hrw: No, this doesn't work as upstart is not started as process #1
[10:50] <nosse1> Perhaps a better scheme would be to make upstart start strace, which attaches itself to init
[10:52] <hrw> or that
[10:54] <Stskeeps> edit preinit instead
[10:54] <Stskeeps> er, nm
[10:55] <nosse1> Yeah, I'm trying to figure out which script is initally called by init
[11:47] <nosse1> How _do_ I debug init? My efforts seems to be useless...
[11:50] <nosse1> Basically the problem is the fact that init has to be process num 1. Its behaviour is altered if not
[11:52] <hrw> nosse1: in first start script attach strace to init
[11:57] <nosse1> What is the first start script? I mean init read all scrits in /etc/init and then executes the ones with "start on startup". How to ensure my script comes first?
[11:58] <hrw> I use sysvinit still ;(
[11:59] <nosse1> Ah
[13:36] <asac> ndechesne: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid
[13:36] <asac> example
[13:40] <hrw> asac: how good ti-omap branch of ubuntu-lucid kernel works?
[13:41] <asac> hrw: was told it boots, but no graphics output (e.g. just serial)
[13:41] <asac> also it has a broken AUFS so it cannot run our liveimages
[13:42] <hrw> ok
[13:45] <amitk> hrw: serial console on babbage for now, hopefully DSS2 by next week.
[13:46] <amitk> s/babbage/beagle
[13:46] <amitk> *sigh*
[13:47] <hrw> amitk: s/beagle/beagleboard
[13:47] <hrw> I remember 'beagle' PDA
[13:47] <hrw> ;D
[13:47] <nosse1> The ti-omap branch in the ubuntu kernel, which targets are they for?
[13:49] <amitk> nosse1: *all* OMAP3 boards for a small definition of *all* :)
[13:50] <amitk> all = boards we have access to - beagleboard, n900
[13:50] <nosse1> I'm working on getting the AM3517 up and running, so I was curious how much I can use from the ti-omap brancj
[13:50] <amitk> I'm going to enable all boards that compile in the 2.6.33 mainline tree
[13:51] <amitk> but I am not going to verify that each peripheral on all these boards works
[13:51] <nosse1> I have to admit it really heavy when you dont have an initial system to start from :(
[13:51] <ndechesne> asac: thanks, this is working. you guys should enable the option in gitweb so that it displays the link in the project summary ;-)
[13:54] <nosse1> amitk: I thought each SoC type have to have its own kernel config. So the common factor between the beagleboard and the n900 is the OMAP3xxx?
[13:55] <amitk> nosse1: OMAP code is structured so that multiple boards can boot off a single kernel (assuming the right bootloader on each board)
[13:55] <amitk> it's more x86-like, in that sense with runtime detection of SoC features
[13:56] <nosse1> amitk: The board is one thing to compile for, another thing is the internal features/peripherals inside the SoC
[13:56] <nosse1> I'm wondering how different the OMAP3 is from the AM3517 (which is an industrial spinoff from the OMAP series)
[13:57] <amitk> nosse1: I made a statement about that earlier: 15:50 < amitk> I'm going to enable all boards that compile in the 2.6.33 mainline tree
[13:57] <amitk> 15:51 < amitk> but I am not going to verify that each peripheral on all these boards works
[13:58] <amitk> nosse1: the core SoC portions should work for all boards. But specifics like a particular display, gpio-connected peripheral, etc. might not work since I don't have HW nor time to verify it on all these boards.
[13:58] <amitk> but I'll accept reasonable patches that are already upstream.
[13:58] <nosse1> OK, let me take it back three steps. We are developing a product based on the TI AM3517 and now I'm trying to bringup the AM3517-EVM.
[13:59] <nosse1> We are evaluating to use Ubuntu Lucid in this product, however, I have spent significant hours getting Ubuntu to boot on target
[14:01] <nosse1> I get it to boot, but it fails during upstart. What, why and where of this failure is unknown
[14:02] <nosse1> I suspect the kernel (since this is cross compiled), so I'd like to make a native ubuntu kernel from the TI kernel branch. However this is also not as easy as it looks
[14:03] <nosse1> I.e. how do you compile a native kernel when you dont have a native system to run on...
[14:03] <amitk> nosse1: I've already enabled AM3517 EVM board in the kernel as you've already realised. The rest is WIP and I'm sure things will get fixed if you file bugs or report them to us
[14:03] <nosse1> Ah...
[14:04] <amitk> (otherwise the kernel probably wouldn't boot on your system)
[14:05] <amitk>     *** OMAP Board Type ***                                                          │ │
[14:05] <nosse1> We had some discussion yesterday that lucid wont boot without initrd image
[14:05] <amitk>   │ │               [*] OMAP3 BEAGLE board                                                               │ │
[14:05] <amitk>   │ │               [*] OMAP3 LDP board                                                                  │ │
[14:05] <amitk>   │ │               [*] Gumstix Overo board                                                              │ │
[14:05] <amitk>   │ │               [*] OMAP 3530 EVM board                                                              │ │
[14:05] <amitk>   │ │               [*] OMAP3517/ AM3517 EVM board                                                       │ │
[14:05] <amitk>   │ │               [*] OMAP3 Pandora                                                                    │ │
[14:05] <amitk>   │ │               [*] OMAP3 Touch Book                                                                 │ │
[14:05] <amitk>   │ │               [*] OMAP 3430 SDP board                                                              │ │
[14:05] <amitk>   │ │               [*] Nokia RX-51 board                                                                │ │
[14:05] <amitk>   │ │               [*] OMAP3 Zoom2 board                                                                │ │
[14:05] <amitk>   │ │               [*] OMAP3630 Zoom3 board                                                             │ │
[14:05] <amitk>   │ │               [ ] CompuLab CM-T35 module                                                           │ │
[14:05] <amitk>   │ │               [*] IGEP0020                                                                         │ │
[14:05] <amitk>   │ │               [*] OMAP3630 SDP board                                                               │ │
[14:05] <amitk>   │ │               [*] OMAP3 debugging peripherals
[14:05] <hrw> amitk: resulting kernel is not granted to boot and work on all of them
[14:05] <amitk> list of boards compiled-in ^^^^^^^^^6
[14:06] <amitk> nosse1: we won't *support* that configuration, but surely it will boot if you make it :)
[14:06] <nosse1> I'll happily test it :D
[14:06] <nosse1> Is the support enabled in the package "linux-image-2.6.33-500-omap" from the lucid repo? Is that it?
[14:07] <amitk> hrw: if you have the right bootloaders for each board, why not?
[14:07] <amitk> hrw: we can't provide bootloaders for them all though
[14:08] <hrw> amitk: I discussed that with few people from OE which use omap3 - some combinations do not boot
[14:08] <hrw> but it was 2.6.29 mostly so things should improve
[14:10] <nosse1> This means that TI are diciplined that the internal resources/registers/peripherals are placed at the same address for all their SoCs
[14:10] <amitk> hrw: lots of work has gone in since 2.6.29 to get multiple boards and multiple SoCs (omap2/3/4) boot from a single kernel.
[14:11] <amitk> nosse1: that and there is runtime detection of features.
[14:11] <nosse1> How do you detect the board?
[14:11] <amitk> mach id
[14:12] <amitk> passed by bootloader
[14:12] <nosse1> Ah. So when we mfg our own HW product, we need to assign a new mach id
[14:12] <hrw> nosse1: new machine id is simple to get
[14:13] <amitk> nosse1: right, new board, new mach id, less headaches for all :)
[14:13] <hrw> nosse1: http://www.arm.linux.org.uk/developer/machines/?action=new
[14:14] <hrw> http://www.arm.linux.org.uk/developer/machines/ gives list
[14:14] <nosse1> Where and who assigns these? And do you happen to have an URL to the location in the kernel where this mach id is checked?
[14:15] <nosse1> *checking list*
[14:17] <nosse1> Interesting... The AM3517 is not found in the list
[14:18] <nosse1> There's one OMAP3517EVM, but I have no idea if the OMAP3517 and AM3517 are compatible
[14:18] <amitk> http://www.arm.linux.org.uk/developer/machines/list.php?id=2200
[14:18] <amitk> nosse1: they are, look at the board config I pasted above
[14:18] <nosse1> Yes, and it's not the same SoC
[14:19] <amitk> runtime detection to turn of features that are not present...
[14:20] <hrw> TI renamed boards some time ago
[14:20] <nosse1> OK, so theres no OMAP3517 in production (replaced by/renamed to AM3517)
[14:21] <hrw> nosse1: no omap3517evm - omap3517 is cpu name
[14:22] <nosse1> OK. The CPU I'm sitting next to is called AM3517 and no OMAP in its name. Nor in the docs from TI
[14:22] <nosse1> How do I send the mach ID to the kernel "mach=2200" ?
[14:36] <nosse1> How should the bootloader tell the kernel which board/machine its on?
[14:37] <hrw> nosse1: arm.linux.org.uk has docs
[14:37] <nosse1> hrw: thanks
[14:50] <nosse1> ok, the AM3517-EVM is not supported from the omap kernel in lucid AFAICS
[14:50] <nosse1> "Error: unrecognized/unsupported machine ID (r1 = 0x80e6189c)."
[14:52] <nosse1> Hmm... The machine ID reported by the kernel has far more information than what is expected: "00000898	OMAP3517/AM3517 EVM"
[14:54] <nosse1> What bootloaders are you guys running on your OMAP targets? I'm using u-boot as delivered out-of-box by TI
[14:54] <amitk> nosse1: I'd be willing to take patches if you find out the root cause.
[14:54] <amitk> we use u-boot
[14:54] <hrw> u-boot
[14:54] <hrw> currently I do not have development arm device without u-boot
[14:55] <nosse1> AM3517 should be supported (it's in the list). It's the machine ID which isn't properly/correctly set by u-boot
[14:55] <hrw> simple patch help
[14:55] <nosse1> of kernel or of u-boot?
[14:56] <hrw> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-2.6.29/ep93xx/edb9301-fix-machine-id.patch is example
[14:56] <hrw> kernel
[14:57] <nosse1> *ush* I'd hoped u-boot.... :(  How do you guys rebuild the kernel without a running target system. qemu?
[14:58] <nosse1> (sorry, I'm not ungrateful. Thanks!)
[15:02] <hrw> nosse1: crosscompilation über alles
[15:03] <nosse1> hrw, danke
[15:03] <hrw> USBHDD is usually bigger then device which I would connect it to
[15:03] <hrw> and mmc cards are too slow
[15:07] <nosse1> hrw, I don't think its the machine id list which needs patching. Since the reported machine id from the kernel/u-boot is 0x80e618cc it could indicate that the machine is set another way in the u-boot I have
[15:07] <nosse1> I should expect a 0x00000898
[15:07] <hrw> nosse1: check?
[15:07] <nosse1> I'll check the sources of u-boot
[15:08] <nosse1> Because the TI's own kernel branch is capable of detecting the machine from this version of u-boot
[15:09] <nosse1> Is it probable that the way the machine ID is transferred from BL to kernel has changed?
[15:09] <amitk> what version is the TI kernel?
[15:09] <nosse1> 2.6.32
[15:12] <amitk> I'd check for changes in arch/arm/mach-omap2/board-am3517evm.c between TI and Lucid
[15:12] <lool> NCommander, asac: Hey can you folks please take care of the diff which Sarvatt sent to fix -dove xorg compilation with Xorg 1.7?  :-)   See http://sarvatt.com/downloads/patches/xserver-xorg-video-dove.diff
[15:13] <lool> Sarvatt: [ Would be great if you could clarify whether it's expected to still build with <= 1.6 to NCommander and asac ]
[15:13] <Sarvatt> lool: NCommander responded yesterday saying he got a new code drop that fixed it already so it wasn't needed :D
[15:14] <asac> ah
[15:14] <asac> kk
[15:15] <lool> Sarvatt: Oh good news; I hope he could share it with you already
[15:15] <nosse1> Ah. There's lots of changes (additions) in the arch/arm/mach-omap2/board-am3517evm.c from the lucid source to the TI source.
[15:15] <lool> Sarvatt: It would be great to check we're not missing anything from your diff
[15:18] <Sarvatt> not yet unfortunately, but I'll check it out. I just backported all of the fbdev changes since it was forked off
[15:37] <ndechesne> amitk: was looking at the enforce script in the kernel tree, looks like you don't enforce for ARM_THUMB support. I think it should be there. it took us a while to realize it was missing in our kernel ;-)
[15:41] <asac> ndechesne: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/
[15:44] <nosse1> Yeah!  I finally god my AM3517 to boot the ubuntu lucid kernel!
[15:45] <nosse1> Unfortunately the kernel crashes immideately with a stack dump :(
[15:45] <Martyn> that's not exactly a boot :)
[15:45] <Martyn> -heh-
[15:45] <rsalveti> hahah :-)
[15:45] <nosse1> hah
[15:45] <asac> ndechesne: ubumirror
[15:46] <Martyn> I now have both the tegra2 and (undisclosed platform) purring away nicely
[15:46] <ndechesne> asac: thanks
[15:46] <lool> ndechesne: ubumirror
[15:46] <Martyn> I have to say that >1.1GHz and multi-core makes a huge difference.. but what really causes these chips to rock is the massive amount of L2 cache
[15:47] <amitk> ndechesne: good point! I guess we should have two versions of the script - enfore-platform and enfore-arm
[15:47] <amitk> ndechesne: we've only used it for platform-wide config options until now
[15:48] <nosse1> rsalveti: Morning
[15:49] <rsalveti> morning
[15:49] <rsalveti> nosse1: still fighting with upstart? or a different kernel?
[15:49] <Martyn> nosse1 : What's causing the stack dump?
[15:49] <ndechesne> amitk: ok, i didn't know that. i think and -arm would be good to have then, and perhaps even arm sub arch as well...
[15:49] <amitk> ndechesne: yeah, will talk it over and see the best way to implement it
[15:50]  * Martyn grumbles .. I'm only -one- package away from being able to build hiphop on ARM
[15:50] <nosse1> rsalveti: I've discovered that the lucid kernel package linux-2.6.33-500-omap has support for the AM3517, so I have tried that one
[15:50] <Martyn> they frigging decided to use Intel tbb .. and it doesn't have ARM support, libtbb2 doesn't build on arm
[15:50] <nosse1> Martyn: [   17.504730] Failed to add route LOUT->Line Out
[15:50] <nosse1> [   17.509277] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[15:51] <Martyn> nosse1 : Okay, so it's the sound subsystem that's failing.   Do you need audio?
[15:51] <nosse1> No not to bring up my system
[15:52] <Martyn> okay, because that's hiding in platform_device.h
[15:52] <rsalveti> nosse1: oh, got it :-)
[15:52] <Martyn> just disable audio in the kernel config, recompile .. it will at least get you past that nonsense
[15:53] <Martyn> BRB -- need to reboot this system to try out a new kernel
[15:53] <nosse1> Martyn: Ok, thats coming back to a dilemma I've had recently: How do I recompile the kernel?
[15:53] <Martyn> ( and since it's the hypervisor kernel I'm changing .. -sigh-
[15:53] <Martyn> Don't you hate it when Dom0 needs to be restarted?
[15:53] <rsalveti> nosse1: you can cross-compile it or compile it at a native environment
[15:53] <rsalveti> nosse1: at a native environment you can use qemu user mode emulation, but takes time
[15:54] <nosse1> rsalveti: Yes, your help in that respect works like a charm
[15:54] <rsalveti> if you have access to emulated environment, just get the kernel source and build it normally
[15:55] <rsalveti> you can even use the deb src to do that
[15:56] <nosse1> How do I alter the config? Because deb/ubuntu has its own mechanism for setting .config, right?
[15:59] <rsalveti> nosse1: hm, need to check for lucid, as I never built the lucid kernel by hand
[15:59] <rsalveti> nosse1: but you can check the package rules
[15:59] <rsalveti> let me check the source
[16:04] <nosse1> Thats a general question I've had for some time: How do I build kernel for Ubuntu? Or more precisely, what do I need to add to the kerneltree for it to build for ubuntu
[16:05] <nosse1> Add the debian* directories into the source tree, right?
[16:06] <lool> nosse1: There are multiple ways
[16:06] <lool> nosse1: Just building the ubuntu source with ubuntu config and outputting zImage or uImage doesn't need any packaging stuff
[16:07] <lool> nosse1: If you want .debs, you can either use Debian's kernel-package approach which will not create the same stuff we do, but has more documentation, or you can copy our debian/ and modify it to build what you want; see kernel.ubuntu.com for the latter approach
[16:08] <prpplague> anyone else experience weird problems with Xorg and HAL when configuring items like touchscreens?
[16:09] <nosse1> lool: Thanks. How do I get the kernel config from a kernel source (from ubuntu source)? It's obviously not stored in .config
[16:17] <lool> nosse1_noob: It's in debian.nameoftree/config
[16:17] <lool> nosse1_noob: split into ubuntu common, architecture common, and flavour specific files
[16:17] <lool> Just cat them together
[16:17] <lool> nosse1_noob: Another efficient way is to get it from a binary kernel .deb
[16:18] <lool> nosse1_noob: See "debian/rules updateconfigs" doc on the kernel wiki
[16:21] <armin76> lool: i have better hardware than you! :P
[16:23] <prpplague> armin76: what hardware do you have?
[16:26] <armin76> prpplague: tegra2 :)
[16:27] <prpplague> armin76: ahh
[16:31] <hrw> armin76: how is tegra2 when it comes to linux support?
[16:31] <armin76> hrw: i have it working with no problems...
[16:31] <armin76> the only problems i have are:
[16:31] <armin76> -no wifi/bt driver
[16:32] <armin76> -sound doesn't work
[16:32] <hrw> armin76: but do they publish patches or NDA only?
[16:32] <armin76> -obviusly no Xorg driver
[16:32] <armin76> hrw: patches for what?
[16:32] <armin76> for the kernel? they have a public git
[16:32] <hrw> nice
[16:33] <hrw> as this is nvidia I rather supposed 'give us all your body parts for patches' type of license
[16:33] <prpplague> armin76: what do you like/dislike about the physcial board's features and layout?
[16:34] <armin76> prpplague: i dislike missing sata :)
[16:34] <armin76> the cpu doesn't have neon either
[16:34] <armin76> but apart from that, its really complete
[16:35] <armin76> takes 9 mins to build binutils vs 30m on the efika mx(imx515 800mhz)
[16:50] <Martyn> nosse1 : Did you get an answer to your cross-compilation question?
[16:51] <prpplague> armin76: ahh
[16:51] <prpplague> armin76: what about the overall layout of the board? makes it easy to work with on desktop? and/or interface to?
[16:51] <prpplague> armin76: you doing any custom hardware with it?
[16:54] <lool> robclark: http://people.canonical.com/~lool/loop-mnt-do
[16:54] <robclark> thx
[16:56] <armin76> prpplague: hrm...yes, and no, not doing any custom hardware with it, i'm a distro dev, not hw dev :)
[16:57] <nosse1_noob> Martyn: yes, thank you. I'm compiling semi-natively using the qemu chroot environment right now. Takes a while!
[16:58] <Martyn> Yeah, cross-compiling is faster by far
[16:58] <Martyn> I use a dual cpu, quad core nehalem system w/ hyperthreading enabled
[16:59] <Martyn> 16 cores to distribute the compile means I generally get kernels in < 2min
[16:59] <Martyn> (35 seconds being the record for a full make clean uImage modules modules_install
[17:00] <nosse1_noob> *bah* I'm compiling on Dell laptop (Core2Duo @3.06G)
[17:00] <Martyn> that means you can at least do make -j4
[17:00] <Martyn> and that will speed things up anyway
[17:01] <armin76> Martyn: thats not the ubuntu way! :P
[17:02] <hrw> armin76: kernel in 2 or 20 minutes? this makes difference
[17:02] <nosse1_noob> Does the HT scale into "make -j2"? I thought it didnt. That you could only specify the number of cores, not logical HT's?
[17:02] <Martyn> nosse : -j only specifies the number of jobs...
[17:03] <Martyn> as it turns out, yes .. compilation is a -great- test of hyperthreading
[17:03] <Martyn> I get a very effective compile at -j16
[17:03] <Martyn> (with eight cores)
[17:03] <Martyn> if I was doing floating point.. then HT would totally not help
[17:04] <nosse1_noob> Is there significant difference in the timing of -j16 and -j8 ?
[17:04] <nosse1_noob> Because that would IMHO be profiling how well the HT works
[17:05] <Martyn> Yep .. almost 1/3 the compile time :)
[17:05] <prpplague> armin76: thanks for the info
[17:06] <nosse1_noob> Impressive. I would it expect it to scale more or less linearly
[17:06] <armin76> prpplague: for example i don't think a beagle is nice to work with on the desktop, i don't have one, but thats the feel it gives to me, too small...
[17:06] <prpplague> armin76: yea
[17:06] <prpplague> armin76: the tegra2 have any desktop case available?
[17:07] <armin76> prpplague: nope
[17:07] <Martyn> no
[17:07] <Martyn> but it's easy enough to cobble together a case
[17:07] <Martyn> mind you, the board is SIX INCHES on a side :)
[17:07] <prpplague> armin76: does having a generic case of some type add anything to getting a dev board for you?
[17:07] <Martyn> so it's not like putting it in a case would be very smart :)
[17:08] <prpplague> Martyn: yea you can get some generic pactec or okwusa abs plastic cases
[17:08] <prpplague> i know alot of software dev folks like to have boards in a case of sometype
[17:08] <armin76> prpplague: i'd like to, yes
[17:11] <zumbi> armin76: yab? -- yet another board? -- mami is going to kick you out from home :-P
[17:11] <prpplague> armin76: not specifically targeted towards the tegra2 , but something like this http://www.okwusa.com/products/okw/interface-terminal.htm  , would that interest you ?
[17:13] <zumbi> prpplague: is the case coming with some processing unit?
[17:14] <prpplague> zumbi: yea
[17:15] <zumbi> which one?
[17:15] <prpplague> just discussion ATM
[17:16] <armin76> prpplague: i guess
[17:17] <prpplague> armin76: there are a number of other cases on the okwusa.com site, if you see one that catches your eye, i'd be curious
[17:18] <armin76> prpplague: the one with aluminium looks nice :)
[17:20] <prpplague> armin76: which one is that?
[17:21] <armin76> prpplague: http://www.okwusa.com/products/okw/interface-terminal/zoom/zB4146106.jpg
[17:22] <prpplague> armin76: ahh
[17:22] <armin76> and i'd prefer a different color instead of white :)
[17:25]  * Martyn really doesn't bother with cases
[17:26] <Martyn> I just get a piece of wood (or ABS plastic) as a base, put stands w/ standoffs, and that's pretty much that
[17:27] <prpplague> armin76: hehe, you can get, navy blue, fire engine red, explosive yellow, and hot pink
[17:27] <prpplague> Martyn: yea that is pretty common
[17:28] <Martyn> I do it so the dev boards won't get lost
[17:29] <prpplague> hehe indeed
[17:30] <prpplague> Martyn: i like to use laminated shelf boards, basically "extra shelf" boards you can buy at most hardware stores
[17:31] <Martyn> They are -just- heavy enough that I don't use them
[17:31] <Martyn> Generally I either use 5mm (1/4") plywood, or 1/4" ABS cut to size
[17:32] <prpplague> Martyn: i like the shelves since i have on the bookshelf units that they go in, that way when i don't need the board, i simply put it in the bookshelv
[17:33] <Martyn> HEH!  cute :)
[17:35] <prpplague> Martyn: i notice you are in the #arduino channel
[17:36] <prpplague> Martyn: you done anything with ubuntu on the beagleboard?
[17:49] <hrw> re
[17:49] <hrw> Martyn: 6.7" size is better as this is 17cm == mini-itx factor so very easy to get a case (but not necessary cheap)
[18:08] <Martyn> prpplague : Yeah, I finished a karmic port .. then moved on to bigger fish
[18:08] <Martyn> prpplague : The beagle is just too slow and clunky compared to the other boards here at work .. it kind of sits in the corner
[18:09] <hrw> prpplague: can you share pictures of your 'unused devboards bookshelf'?
[18:29] <davilla> anyone ever build arm-2009q1 from codesourcery native on ubuntu 9.04 ?
[18:30] <davilla> native on arm that is.
[18:32] <nosse1> Is there any difference between gcc compiled for ubuntu and the codesourcery (arm-none-linux-gnueabi) when compiling the kernel?
[18:32] <armin76> davilla: may want to ask on #efika about that kind of experiments, not sure if they are using ubuntu or not, though...
[18:33] <hrw> nosse1: you mean vanilla gcc/binutils/glibc contra CSL one?
[18:33] <armin76> i think they do,  i may be wrong
[18:33] <davilla> thx, armin76
[18:34] <nosse1> hrw, I'm trying to cross build the kernel and for that I'm using the CSL version
[18:34] <nosse1> I remember that theres a kernel option which is to enable the EABI -- I don't know what the alternative is
[18:34] <armin76> nosse1: you don't have crosscompilers on ubuntu afaik
[18:34] <armin76> nosse1: the alternative is OABI :)
[18:35] <Martyn> armin76 : Yes there are .. just not for ARM :)
[18:35] <Martyn> avr-gcc is an example ...
[18:35] <Martyn> nosse1 : For a standard EABI compiler, use the toolchain provided by CodeSourcery
[18:35] <hrw> Martyn: or build own
[18:35] <Martyn> It has the latest vfp hard float support, and is an optimized toolchain.   the G++ toolchain is free
[18:36] <nosse1> I need to recompile the kernel (Ubuntu Lucid), and doing it from qemu chroot takes *ages*
[18:36] <nosse1> I hoped I could cross compile it using the CSL one
[18:36] <Martyn> hrw : crosstool-ng is broken for EABI right now .. there are checkins coming from CodeSourcery to fix it, but for the moment it's easier to grab their precompiled toolchain
[18:36] <armin76> Martyn: or use gentoo! :)
[18:36] <hrw> Martyn: I usually do 'bitbake meta-toolchain' and have toolchain built
[18:37]  * armin76 does crossdev $CHOST
[18:37] <hrw> but thats due to my OE experience
[18:37] <Martyn> hrw : It's the source for GCC that's broken (4.4) .. not the crosstools
[18:37] <nosse1> Ah, so you're familiar with OE
[18:38] <Martyn> Then again, I'm more sensitive to toolchain breakage at the moment, since i'm quite literally on the bleeding edge of ARM tech
[18:38] <nosse1> hrw, we are trying to decide if we are going to use OE or Debian for our next product
[18:38] <hrw> nosse1: yep, 6 years of using
[18:38] <armin76> nosse1: ubuntu!
[18:38] <nosse1> hrw, as you probably have heard from my complaining, I haven't had an easy introduction to ubuntu arm :)
[18:38] <hrw> nosse1: OE gives you automation of building
[18:39] <hrw> Debian/Ubuntu gives you bigger repository of software but also bigger storage requirements
[18:39] <armin76> hrw: what about gentoo!
[18:40] <hrw> my first LinuxPDA (Zaurus SL-5500) had 14.4MB for rootfs and we got X11 in it with pim and settings stuff (wifi/bt covered)
[18:40] <hrw> armin76: never used
[18:40] <hrw> armin76: as each gentoo build is different from other I prefer to not support it
[18:40] <nosse1> we have a total NAND flash of 1G, so ubuntu lucid is fine
[18:40] <Martyn> armin76 : gentoo on ARM is a huge PAIN IN THE BUTT
[18:40] <Martyn> -heh-
[18:41] <hrw> nosse1: one big ubifs on it?
[18:41] <Martyn> build-from-source is not the best way to get customers happy.   gentoo is for people who are system performance fetishists :)
[18:41] <nosse1> hrw, something like that
[18:42] <nosse1> Martyn, in our product everything behind the end-user application will be hidden. The customer will not know (or care) which distro is running in the scenes
[18:42] <hrw> Martyn: if you give customers rootfs + repository of packages they will not see that
[18:43] <armin76> hrw: isn't the same with OE?
[18:43] <Martyn> hrw : The way gentoo works, a repository of packages = a repository of source packages.  They get compiled every time
[18:43] <Martyn> it's not like .ipk's, .deb's, or .rpm's
[18:43] <nosse1> But the customer will need upgrades and security fixes, and apt-get fixes that in a very elegant way!
[18:43] <Martyn> one of gentoo's base requirements is a full toolchain /must/ exist on the target system
[18:43] <nosse1> So my personal choice (from experience with desktop Ubuntu) is to use Ubuntu on this target
[18:44] <rsalveti> nosse1: I think this is something that ubuntu behaves better, with oe you'll need to build the repository/rootfs image and update it with your custom method
[18:44] <hrw> bb in few
[18:45] <nosse1> rsalveti, I agree. But my boss wont let me spend countless hours on this unless I am capable of getting my AM3517 up and running
[18:46] <rsalveti> nosse1: haha, sure, but it seems that your bigger problem now is that your kernel is not booting fine yet
[18:46] <rsalveti> and this is something that doesn't depends on which distro
[18:46] <nosse1> hehe, yes, true
[18:46] <rsalveti> nosse1: with oe you can rebuild the kernel easily because it's cross-compiled
[18:47] <rsalveti> if you set up your cross-compile environment, you'll get the same speed, but can be a pain in the ass :-)
[18:47] <rsalveti> oe sets up the cross compiler for you easily
[18:47] <Martyn> As I was saying -- download CodeSourcery G++ lite, install it on your favorite multi-core X86 system, and use that
[18:47] <Martyn> set ARCH=arm
[18:48] <Martyn> set CROSS_COMPILE=(wherever you installed CodeSourcery)/bin/arm-eabi-none-
[18:48] <rsalveti> yeah, I think this will be enough for you, until you get the kernel booting fine
[18:48] <Martyn> and poof .. you're off to the races
[18:48] <nosse1> Martyn, that's what I've done
[18:48] <Martyn> (assuming you want an eabi toolchain)
[18:48] <nosse1> Now it's on me: I'm trying to rebuild the kernel. Just need to shave off some config
[18:48] <Martyn> I'm compiling with a thumb2-ee toolchain now .. eabi, and a pain in the butt
[18:50] <nosse1> Martyn: I have the arm-none-linux-gnueabi- cross from CS. I can use that one, right?
[18:50] <nosse1> And I need to enable the EABI setting in the kernel config, as well
[18:51] <armin76> if you don't iirc ubuntu won't run on it
[18:54] <nosse1> Ah. Because I was uncertain if I should download the arm-none-eabi vs. the arm-none-linux-gnueabi
[18:55] <Martyn> nosse1 : That's the one
[18:56] <nosse1> Martyn, sorry which? none-eabi or none-linux-gnueabi ?
[18:56] <armin76> lol
[18:56] <Martyn> gnueabi (it's the same)
[18:56] <nosse1> Thanks!
[18:56] <Martyn> it's just the triplet-name CodeSourcery chose when they created the toolchain
[18:57] <nosse1> Isn't it because they have libc bundeled along with it? (Which the kernel ignores anyway)
[19:02] <hrw> re
[19:03] <nosse1> I got this while compiling: "ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8974.ko] undefined!"
[19:04] <nosse1> Now, I can disable the driver alltogether, but is this related to the CSL cross compiler?
[19:04] <hrw> nosse1: google should give answer - common problem it was
[19:04] <nosse1> hehe - sorry, you're right
[19:05] <hrw> nosse1: Debian gives you fixes and upgrades often faster then OE - amount of developers scales that
[19:06] <prpplague> hrw: sorry i can't share a picture of the boards currently as most of them are covered under NDA
[19:07] <nosse1> hrw, you mean debian as in the family of debian based distros, or literally debian
[19:07] <hrw> nosse1: family
[19:07] <prpplague> Martyn: i was curious about your beagleboard and arduino usage, since my trainer board for the beagle goes on sale this week
[19:07] <nosse1> hrw, because we are cpnsidering debian, but we want to have a distro targeted for ARMv7, which lucid does
[19:08] <hrw> prpplague: I was more interested of how they look as shelfs - boards can be blurred or even replaced by one color boxes
[19:08] <Martyn> prpplague : We don't use the beagleboard for much
[19:08] <Martyn> prpplague : It was just an early board we grabbed to evaluate the possibity of ARM as a server chip
[19:08] <Martyn> prpplague : And I'm an avid AVR freak :)  I love teaching how to use them
[19:09] <prpplague> Martyn: ahh, http://www.elinux.org/BeagleBoard_Trainer
[19:09] <nosse1> Martyn, I used to work in Atmel :D I'm very familiar with AVRs...
[19:09] <Martyn> NICE board
[19:10] <hrw> have a nice rest of day
[19:10] <prpplague> hrw: you leaving?
[19:10] <prpplague> hrw: i'll see if i find time this weekend to take a picture
[19:10] <hrw> prpplague: 20:10 here and I need to bath my kid
[19:11] <prpplague> hrw: water hose works great
[19:11] <hrw> then cartoon and put kid sleep etc
[19:11] <hrw> prpplague: ;D
[19:11] <prpplague> hrw|gone: later bud
[19:15] <prpplague> Martyn: been looking for someone who has experience with both beagle and avr to tinkering around with the trainer board
[19:15] <prpplague> Martyn: i.e. write some howtos and such
[19:18] <Martyn> Oh ..
[19:18] <Martyn> -heh-
[19:18] <Martyn> I don't have the time, honestly.
[19:18] <Martyn> Work absorbs most of my time, and the new hackerspace (www.austinhackerspace.org) takes up the rest
[19:19] <prpplague> Martyn: ahh dandy you are in austin
[19:20] <Martyn> yep
[19:20] <Martyn> ojn is near me too
[19:20] <prpplague> Martyn: well if i donated a few trainer boards to your hackerspace...........
[19:24] <Martyn> prpplague : They would be very gladly accepted
[19:24] <Martyn> prpplague : And a nice addition to our board shelf
[19:24] <Martyn> prpplague : Where are you located?
[19:25] <prpplague> dallas/ft.worth
[19:25] <prpplague> Martyn: you working with canonical?
[19:26]  * prpplague goes to meeting
[19:34] <nosse1> Ush. Another kernel crash on target
[19:35] <nosse1> I wonder if it would be cheaper to ship you guys an eval board? :o
[19:41] <rsalveti> nosse1: what crash you had now?
[19:42] <nosse1> [   39.828002] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa070004
[19:42] <nosse1> [   39.835723] Internal error: : 1028 [#1]
[19:43] <nosse1> The strange thing is that this kernel works fine when I compile it for OE
[19:46] <rsalveti> nosse1: do you have the complete stack?
[19:46] <rsalveti> nosse1: you mean, the same kernel source?
[19:47] <nosse1> rsalveti, yes. I have the stack. Unless you want it, I want to retry another run here
[19:48] <nosse1> rsalveti, yes the same source
[19:49] <rsalveti> nosse1: does this happen while the kernel is booting or is when upstart is running and loading kernel modules?
[19:50] <nosse1> rsalveti: during kernel boot
[19:51] <nosse1> rsalveti: Since we talked yesterday, I discovered that there is a kernel package in lucid which should have support for AM3517. So I've decided to give that a go. And that's where I am
[19:51] <rsalveti> nosse1: oh, ok
[19:51] <nosse1> In a way, I'm shorter than yesterday, but I feel its more in the right direction
[19:53] <rsalveti> nosse1: yeah, if you already have support with lucid kernel, for sure it's better to keep it than the original ti one
[19:53] <rsalveti> but now you need to fix it :-)
[19:53] <nosse1> :D
[19:57] <hrw|gone> re
[19:57] <hrw|gone> for few minutes
[19:57] <hrw|gone> nosse1: kernel built with OE works but with other toolchain fails?
[19:58] <nosse1> hrw|gone: Yes sort of. The kernel config is different as well, because the kernel config is "ubuntuized"
[19:59] <rsalveti> oh, that could be the reason
[19:59] <hrw|gone> nosse1: try ubuntu config with OE then
[19:59] <rsalveti> yeah, if the toolchain is the same, you _need_ to get the same results :-)
[20:00] <nosse1> Now I got another error: "uncompression error" after building an image
[20:01] <nosse1> Strange. Because it was a make menuconfig; make thing which now fails
[20:03] <nosse1> Are you guys doing any debugging with JTAG for any of the kits?
[20:05] <hrw|gone> I am avoiding jtag as much as possible
[20:06] <nosse1> hrw|gone, are you familiar with Arago or Ångström?
[20:06] <nosse1> Because these are the OE spinoffs which TI endorse in their Linux SDKs
[20:07] <nosse1> AFAIK Arago is a TI maintained version of Ångström
[20:07] <hrw|gone> nosse1: Arago is OE spinoff. Angstrom is 'OE derived' distribution
[20:07] <hrw|gone> I am one of Angstrom creators
[20:08] <nosse1> Aha! I know it's a bit OT here: But why the OE derivation ?
[20:11] <hrw|gone> OE is used to build many distributions. some of them were finished some time ago (OpenZaurus, Familiar, OpenSimpad, OpenBeagle etc), some still live (Angstrom, SlugOS, minimal, micro)
[20:11] <DanaG> rcn-ee: you get a chance to try out suspend/resume?
[20:12] <hrw|gone> micro is distribution made for really embedded devices - no package management on them, no /usr/ hierarchy etc
[20:12] <nosse1> hrw|gone: I know I asked the q earlier, but would you base a production product on Ubuntu? The alternative is the one endorsed by TI, which is Arago then.
[20:13] <hrw|gone> nosse1: angstrom is main distro in OE - supports most of devices, has support from few companies, few hw vendors uses it as a base for their BSP/SDK
[20:13] <nosse1> I need to make a presentation to the SW team soon
[20:14] <hrw|gone> nosse1: personally I would base on OE - easier to alter anything, select components and their versions then in debian and its derivatives
[20:15] <nosse1> Yes I begin to agree, when looking at the number of hours I've logged just for getting the Ubuntu to run on my target
[20:15] <nosse1> And the fact the Ubuntu compiles packages natively, scares some members of my team
[20:16] <hrw|gone> nosse1: with quad core x86-64 you can build rootfs from scratch in few hours using OE (including toolchain, native tools etc).
[20:16] <hrw|gone> sorry ubuntu guys
[20:17] <nosse1> Yes. Cross compiling everything means we can build using our build farm.
[20:18] <hrw|gone> at company for which I work now I have dual quadcore xeon as one buildmachine and quad i7 as second
[20:18] <DanaG> I did find it a bit funny that there's a powerpc cross-compiler in the repos, but no ARM cross-compiler.
[20:18] <nosse1> BUT: apt-get is one of the major reasons for considering deb/ubuntu. My knowledge about ipkg/opkg i limited, but I haven't heard exclusively good news about it
[20:21] <hrw|gone> nosse1: OE can generate deb packages but I do not know how well tested was using apt repositories
[20:22] <hrw|gone> nosse1: I know that rpm repositories worked but prefer to not touch it
[20:22] <rsalveti> hrw|gone: we tested that when we worked with mamona, and did work quite fine
[20:22] <rsalveti> we just weren't able to rebuild it from the package source
[20:22] <nosse1> I tried rpm when working with a Freescale iMX (with LTIB). I dont want to go back to that
[20:23] <nosse1> A package system is a must for us, since we have many individual teams working on different libraries/apps etc. It makes the actual release (building) process much simpler
[20:25] <hrw|gone> nosse1: I worked with few companies which used OE. Most of time it was team with developers which worked on apps/libraries + 1-3 people which also worked on OE integration (so they wrote recipes for soft written by first group and admin company buildbot which gives results for whole team)
[20:27] <nosse1> Yes, I don's say it isn't manageable during development. However, we also need to have a scheme for seamless upgrade by the end-user
[20:28] <nosse1> And apt-get delivers that in a good way IMHO
[20:29] <nosse1> So weird: Now I'm not able to even build a uImage which the kernel can boot from
[20:29] <nosse1> This is getting stranger and stranger
[20:30] <hrw> nosse1: still am3517?
[20:30] <nosse1> yup
[20:31] <nosse1> It hangs during uncompression.... Let's see: uboot load addr 0x82000000. Uimage loadaddr 0x80008000. Entry point 0x80008000
[20:31] <hrw> decompressing linux......
[20:31] <hrw> and thats all?
[20:32] <nosse1> yes, unfortunately
[20:32] <hrw> csl toolchain?
[20:32] <nosse1> yes
[20:33] <hrw> drop it and use OE one?
[20:34] <nosse1> hrw, would it be too much for me to ask how? I mean urls to set it up, please
[20:34] <nosse1> hrw, I have arago, but they are using the CSL as wee
[20:34] <nosse1> s/wee/well/
[20:34] <hrw> nosse1: OE wiki has 'Getting started' page, there are also some helping scripts
[20:35] <hrw> http://gitorious.org/angstrom/angstrom-setup-scripts for example
[20:36] <nosse1> I have a slight memory of something like "bitbake toolchain", right?
[20:36] <hrw> "bitbake meta-toolchain" gives you tarball with toolchain
[20:37] <nosse1> Should I pull OE or Å?
[20:37] <hrw> Angstrom is in mainline OE
[20:37] <nosse1> ah.
[20:40]  * prpplague returns from meeting
[20:40] <hrw> prpplague: wb
[20:41] <prpplague> hrw: critter washed and to bed?
[20:41] <hrw> sort of
[20:42] <nosse1> hrw, so have I got it right if I say that Angstrom is a distro implementation which can be built by OE?
[20:42] <hrw> yes
[20:45] <prpplague> well, this just in, jury has ruled in favor of Novell in the SCO case
[20:50] <nosse1> http://www.groklaw.net/
[20:54] <hrw|gone> bye
[20:54] <nosse1> bye
[20:55] <nosse1> This is SO wierd. One kernel works (i.e. is willing to uncompress and start) while the other is not
[20:56] <nosse1> The ONLY difference between those two is the enabling of CONFIG_SND!
[20:57] <nosse1> ..but now I'm giving up
[20:58] <nosse1> I'll see you guys tomorrow
[20:58] <rsalveti> that's bad, luckly you'll get it running tomorrow
[21:01] <nosse1> bye