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