[00:06] eggonlea: ping? [00:07] eggonlea: if your around, I'd like to poke your brain on Dove stuff [00:07] 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] 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] crimsun: it still doesn't work with that change, that just fixes the issue Li Li brought up [00:08] NCommander: *what* doesn't work? [00:08] crimsun: audio through pulse [00:08] or at lesat, I couldn't get it to work [00:09] what are your test cases, or are you saying that generally audio just doesn't work through PA? [00:09] thats exactly what I'm saying [00:10] ...so, the latteR? [00:10] crimsun: I haven't played a lot with it today, GrueMaster knows more about this than I do [00:10] crimsun: oh, wow, I'm braindead >.>; [00:11] * NCommander goes to grab dinner [01:30] * NCommander returns === bjf is now known as bjf-afk [02:24] NCommander: yes [02:25] eggonlea: mind if I PM you? [02:25] NCommander: I'm updating all components on new Lucid with the latest kernel. [02:26] NCommander: welcome~ :P [02:26] 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] NCommander: which kernel are you using? I think Eric is merging the new LSP today. [02:27] eggonlea: archive latest, but I also tried the BSP on the wiki [02:27] NCommander: OK, please feel free to let me know if I can do anything. [02:28] 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] I'll upload them today [04:21] 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] 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] GrueMaster, so I really suspect it's a permission issue [05:14] GrueMaster: is the thing headless? [05:14] If so, consolekit / policykit may be blocking access to the audio device. [05:15] rcn-ee: did you check out the suspend/resume stuff? === JaMa|Zzzz is now known as JaMa [06:59] DanaG: No, it isn't headless. [06:59] hmm, are policykit and consolekit installed? [07:00] If not, try installing them. [07:03] Is there doc about installing xfce on Beagle ? [07:18] nosse1: was finally able to test the user mode emulation here with the lucid rootfs [07:19] nosse1: please check at the end of https://wiki.ubuntu.com/ARM/RootfsFromScratch [07:20] 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] 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] 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] nosse1: then once you're inside the chroot environment, you can use it to build and test your arm packages/applications [07:23] time to get some sleep :-) [07:31] GrueMaster: using pavucontrol, I was able to move the audio output on Pulse [07:35] Do you already have the changes in /usr/share/pulseaudio/alsa-mixer/paths/? [07:36] Because pavucontrol and sound-applet->preferences have the exact same layout. [07:36] NCommander: ^^^ [07:39] GrueMaster: if they were pushed in archivem, then yes [07:40] 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] GrueMaster: oh, ok [07:40] * NCommander feels dense [07:41] Get some sleep. It helps. [07:46] GrueMaster: not tired :-/ [07:46] eggonlea: ping? [08:15] Good morning everyone [08:42] NCommander: ack. You should go to bed indeed. [08:44] eggonlea: probably, but your still here so :-) [08:46] Hey, I'm in GMT+8 but you NOT! [08:53] eggonlea, NCommander is a superman [08:55] ericm_, Agree! any luck on the new kernel? [08:55] eggonlea, I've filed a difference to you, you check and let me know if everything is OK before I merge [08:58] ericm_, checking... [09:29] ericm, It's fine. Let's move on. :) [09:37] I can't make the keyboard work with Karmic installation === hrw|gone is now known as hrw [10:09] morning [10:09] hi morning [10:11] rsalveti: u8500? where you are working? [10:12] What's the best approach for stracing upstart? Because upstart needs to be process no. 1, right? [10:16] nosse1: "init=strace upstart"? [10:49] hrw: No, this doesn't work as upstart is not started as process #1 [10:50] Perhaps a better scheme would be to make upstart start strace, which attaches itself to init [10:52] or that [10:54] edit preinit instead [10:54] er, nm [10:55] Yeah, I'm trying to figure out which script is initally called by init === jamie is now known as JamieBennett [11:47] How _do_ I debug init? My efforts seems to be useless... [11:50] Basically the problem is the fact that init has to be process num 1. Its behaviour is altered if not [11:52] nosse1: in first start script attach strace to init [11:57] 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] I use sysvinit still ;( [11:59] Ah === jamie is now known as Guest74361 [13:36] ndechesne: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid [13:36] example [13:40] asac: how good ti-omap branch of ubuntu-lucid kernel works? [13:41] hrw: was told it boots, but no graphics output (e.g. just serial) [13:41] also it has a broken AUFS so it cannot run our liveimages [13:42] ok [13:45] hrw: serial console on babbage for now, hopefully DSS2 by next week. [13:46] s/babbage/beagle [13:46] *sigh* [13:47] amitk: s/beagle/beagleboard [13:47] I remember 'beagle' PDA [13:47] ;D [13:47] The ti-omap branch in the ubuntu kernel, which targets are they for? [13:49] nosse1: *all* OMAP3 boards for a small definition of *all* :) [13:50] all = boards we have access to - beagleboard, n900 [13:50] 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] I'm going to enable all boards that compile in the 2.6.33 mainline tree [13:51] but I am not going to verify that each peripheral on all these boards works [13:51] I have to admit it really heavy when you dont have an initial system to start from :( [13:51] 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] 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] nosse1: OMAP code is structured so that multiple boards can boot off a single kernel (assuming the right bootloader on each board) [13:55] it's more x86-like, in that sense with runtime detection of SoC features [13:56] amitk: The board is one thing to compile for, another thing is the internal features/peripherals inside the SoC [13:56] I'm wondering how different the OMAP3 is from the AM3517 (which is an industrial spinoff from the OMAP series) [13:57] 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] 15:51 < amitk> but I am not going to verify that each peripheral on all these boards works [13:58] 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] but I'll accept reasonable patches that are already upstream. [13:58] 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] We are evaluating to use Ubuntu Lucid in this product, however, I have spent significant hours getting Ubuntu to boot on target [14:01] I get it to boot, but it fails during upstart. What, why and where of this failure is unknown [14:02] 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] I.e. how do you compile a native kernel when you dont have a native system to run on... [14:03] 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] Ah... [14:04] (otherwise the kernel probably wouldn't boot on your system) [14:05] *** OMAP Board Type *** │ │ [14:05] We had some discussion yesterday that lucid wont boot without initrd image [14:05] │ │ [*] OMAP3 BEAGLE board │ │ [14:05] │ │ [*] OMAP3 LDP board │ │ [14:05] │ │ [*] Gumstix Overo board │ │ [14:05] │ │ [*] OMAP 3530 EVM board │ │ [14:05] │ │ [*] OMAP3517/ AM3517 EVM board │ │ [14:05] │ │ [*] OMAP3 Pandora │ │ [14:05] │ │ [*] OMAP3 Touch Book │ │ [14:05] │ │ [*] OMAP 3430 SDP board │ │ [14:05] │ │ [*] Nokia RX-51 board │ │ [14:05] │ │ [*] OMAP3 Zoom2 board │ │ [14:05] │ │ [*] OMAP3630 Zoom3 board │ │ [14:05] │ │ [ ] CompuLab CM-T35 module │ │ [14:05] │ │ [*] IGEP0020 │ │ [14:05] │ │ [*] OMAP3630 SDP board │ │ [14:05] │ │ [*] OMAP3 debugging peripherals [14:05] amitk: resulting kernel is not granted to boot and work on all of them [14:05] list of boards compiled-in ^^^^^^^^^6 [14:06] nosse1: we won't *support* that configuration, but surely it will boot if you make it :) [14:06] I'll happily test it :D [14:06] Is the support enabled in the package "linux-image-2.6.33-500-omap" from the lucid repo? Is that it? [14:07] hrw: if you have the right bootloaders for each board, why not? [14:07] hrw: we can't provide bootloaders for them all though [14:08] amitk: I discussed that with few people from OE which use omap3 - some combinations do not boot [14:08] but it was 2.6.29 mostly so things should improve [14:10] This means that TI are diciplined that the internal resources/registers/peripherals are placed at the same address for all their SoCs [14:10] 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] nosse1: that and there is runtime detection of features. [14:11] How do you detect the board? [14:11] mach id [14:12] passed by bootloader [14:12] Ah. So when we mfg our own HW product, we need to assign a new mach id [14:12] nosse1: new machine id is simple to get [14:13] nosse1: right, new board, new mach id, less headaches for all :) [14:13] nosse1: http://www.arm.linux.org.uk/developer/machines/?action=new [14:14] http://www.arm.linux.org.uk/developer/machines/ gives list [14:14] 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] *checking list* [14:17] Interesting... The AM3517 is not found in the list [14:18] There's one OMAP3517EVM, but I have no idea if the OMAP3517 and AM3517 are compatible [14:18] http://www.arm.linux.org.uk/developer/machines/list.php?id=2200 [14:18] nosse1: they are, look at the board config I pasted above [14:18] Yes, and it's not the same SoC [14:19] runtime detection to turn of features that are not present... [14:20] TI renamed boards some time ago [14:20] OK, so theres no OMAP3517 in production (replaced by/renamed to AM3517) [14:21] nosse1: no omap3517evm - omap3517 is cpu name [14:22] 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] How do I send the mach ID to the kernel "mach=2200" ? [14:36] How should the bootloader tell the kernel which board/machine its on? [14:37] nosse1: arm.linux.org.uk has docs [14:37] hrw: thanks [14:50] ok, the AM3517-EVM is not supported from the omap kernel in lucid AFAICS [14:50] "Error: unrecognized/unsupported machine ID (r1 = 0x80e6189c)." [14:52] Hmm... The machine ID reported by the kernel has far more information than what is expected: "00000898 OMAP3517/AM3517 EVM" [14:54] What bootloaders are you guys running on your OMAP targets? I'm using u-boot as delivered out-of-box by TI [14:54] nosse1: I'd be willing to take patches if you find out the root cause. [14:54] we use u-boot [14:54] u-boot [14:54] currently I do not have development arm device without u-boot [14:55] 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] simple patch help [14:55] of kernel or of u-boot? [14:56] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-2.6.29/ep93xx/edb9301-fix-machine-id.patch is example [14:56] kernel [14:57] *ush* I'd hoped u-boot.... :( How do you guys rebuild the kernel without a running target system. qemu? [14:58] (sorry, I'm not ungrateful. Thanks!) [15:02] nosse1: crosscompilation über alles [15:03] hrw, danke [15:03] USBHDD is usually bigger then device which I would connect it to [15:03] and mmc cards are too slow [15:07] 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] I should expect a 0x00000898 [15:07] nosse1: check? [15:07] I'll check the sources of u-boot [15:08] Because the TI's own kernel branch is capable of detecting the machine from this version of u-boot [15:09] Is it probable that the way the machine ID is transferred from BL to kernel has changed? [15:09] what version is the TI kernel? [15:09] 2.6.32 [15:12] I'd check for changes in arch/arm/mach-omap2/board-am3517evm.c between TI and Lucid [15:12] 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] Sarvatt: [ Would be great if you could clarify whether it's expected to still build with <= 1.6 to NCommander and asac ] [15:13] lool: NCommander responded yesterday saying he got a new code drop that fixed it already so it wasn't needed :D [15:14] ah [15:14] kk [15:15] Sarvatt: Oh good news; I hope he could share it with you already [15:15] 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] Sarvatt: It would be great to check we're not missing anything from your diff [15:18] not yet unfortunately, but I'll check it out. I just backported all of the fbdev changes since it was forked off [15:37] 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] ndechesne: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/ [15:44] Yeah! I finally god my AM3517 to boot the ubuntu lucid kernel! [15:45] Unfortunately the kernel crashes immideately with a stack dump :( [15:45] that's not exactly a boot :) [15:45] -heh- [15:45] hahah :-) [15:45] hah [15:45] ndechesne: ubumirror [15:46] I now have both the tegra2 and (undisclosed platform) purring away nicely [15:46] asac: thanks [15:46] ndechesne: ubumirror [15:46] 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] ndechesne: good point! I guess we should have two versions of the script - enfore-platform and enfore-arm [15:47] ndechesne: we've only used it for platform-wide config options until now [15:48] rsalveti: Morning [15:49] morning [15:49] nosse1: still fighting with upstart? or a different kernel? [15:49] nosse1 : What's causing the stack dump? [15:49] 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] 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] 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] they frigging decided to use Intel tbb .. and it doesn't have ARM support, libtbb2 doesn't build on arm [15:50] Martyn: [ 17.504730] Failed to add route LOUT->Line Out [15:50] [ 17.509277] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [15:51] nosse1 : Okay, so it's the sound subsystem that's failing. Do you need audio? [15:51] No not to bring up my system [15:52] okay, because that's hiding in platform_device.h [15:52] nosse1: oh, got it :-) [15:52] just disable audio in the kernel config, recompile .. it will at least get you past that nonsense [15:53] BRB -- need to reboot this system to try out a new kernel [15:53] Martyn: Ok, thats coming back to a dilemma I've had recently: How do I recompile the kernel? [15:53] ( and since it's the hypervisor kernel I'm changing .. -sigh- [15:53] Don't you hate it when Dom0 needs to be restarted? [15:53] nosse1: you can cross-compile it or compile it at a native environment [15:53] nosse1: at a native environment you can use qemu user mode emulation, but takes time [15:54] rsalveti: Yes, your help in that respect works like a charm [15:54] if you have access to emulated environment, just get the kernel source and build it normally [15:55] you can even use the deb src to do that [15:56] How do I alter the config? Because deb/ubuntu has its own mechanism for setting .config, right? [15:59] nosse1: hm, need to check for lucid, as I never built the lucid kernel by hand [15:59] nosse1: but you can check the package rules [15:59] let me check the source [16:04] 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] Add the debian* directories into the source tree, right? [16:06] nosse1: There are multiple ways [16:06] nosse1: Just building the ubuntu source with ubuntu config and outputting zImage or uImage doesn't need any packaging stuff [16:07] 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] anyone else experience weird problems with Xorg and HAL when configuring items like touchscreens? [16:09] lool: Thanks. How do I get the kernel config from a kernel source (from ubuntu source)? It's obviously not stored in .config === nosse1 is now known as nosse1_noob [16:17] nosse1_noob: It's in debian.nameoftree/config [16:17] nosse1_noob: split into ubuntu common, architecture common, and flavour specific files [16:17] Just cat them together [16:17] nosse1_noob: Another efficient way is to get it from a binary kernel .deb [16:18] nosse1_noob: See "debian/rules updateconfigs" doc on the kernel wiki [16:21] lool: i have better hardware than you! :P [16:23] armin76: what hardware do you have? [16:26] prpplague: tegra2 :) [16:27] armin76: ahh [16:31] armin76: how is tegra2 when it comes to linux support? [16:31] hrw: i have it working with no problems... [16:31] the only problems i have are: [16:31] -no wifi/bt driver [16:32] -sound doesn't work [16:32] armin76: but do they publish patches or NDA only? [16:32] -obviusly no Xorg driver [16:32] hrw: patches for what? [16:32] for the kernel? they have a public git [16:32] nice [16:33] as this is nvidia I rather supposed 'give us all your body parts for patches' type of license [16:33] armin76: what do you like/dislike about the physcial board's features and layout? [16:34] prpplague: i dislike missing sata :) [16:34] the cpu doesn't have neon either [16:34] but apart from that, its really complete [16:35] takes 9 mins to build binutils vs 30m on the efika mx(imx515 800mhz) [16:50] nosse1 : Did you get an answer to your cross-compilation question? [16:51] armin76: ahh [16:51] armin76: what about the overall layout of the board? makes it easy to work with on desktop? and/or interface to? [16:51] armin76: you doing any custom hardware with it? [16:54] robclark: http://people.canonical.com/~lool/loop-mnt-do [16:54] thx [16:56] prpplague: hrm...yes, and no, not doing any custom hardware with it, i'm a distro dev, not hw dev :) [16:57] Martyn: yes, thank you. I'm compiling semi-natively using the qemu chroot environment right now. Takes a while! [16:58] Yeah, cross-compiling is faster by far [16:58] I use a dual cpu, quad core nehalem system w/ hyperthreading enabled [16:59] 16 cores to distribute the compile means I generally get kernels in < 2min [16:59] (35 seconds being the record for a full make clean uImage modules modules_install [17:00] *bah* I'm compiling on Dell laptop (Core2Duo @3.06G) === JaMa is now known as JaMa|Away [17:00] that means you can at least do make -j4 [17:00] and that will speed things up anyway [17:01] Martyn: thats not the ubuntu way! :P [17:02] armin76: kernel in 2 or 20 minutes? this makes difference [17:02] 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] nosse : -j only specifies the number of jobs... [17:03] as it turns out, yes .. compilation is a -great- test of hyperthreading [17:03] I get a very effective compile at -j16 [17:03] (with eight cores) [17:03] if I was doing floating point.. then HT would totally not help [17:04] Is there significant difference in the timing of -j16 and -j8 ? [17:04] Because that would IMHO be profiling how well the HT works [17:05] Yep .. almost 1/3 the compile time :) [17:05] armin76: thanks for the info [17:06] Impressive. I would it expect it to scale more or less linearly [17:06] 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] armin76: yea [17:06] armin76: the tegra2 have any desktop case available? [17:07] prpplague: nope [17:07] no [17:07] but it's easy enough to cobble together a case [17:07] mind you, the board is SIX INCHES on a side :) [17:07] armin76: does having a generic case of some type add anything to getting a dev board for you? [17:07] so it's not like putting it in a case would be very smart :) [17:08] Martyn: yea you can get some generic pactec or okwusa abs plastic cases [17:08] i know alot of software dev folks like to have boards in a case of sometype [17:08] prpplague: i'd like to, yes [17:11] armin76: yab? -- yet another board? -- mami is going to kick you out from home :-P [17:11] 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] prpplague: is the case coming with some processing unit? [17:14] zumbi: yea [17:15] which one? [17:15] just discussion ATM [17:16] prpplague: i guess [17:17] 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] prpplague: the one with aluminium looks nice :) [17:20] armin76: which one is that? [17:21] prpplague: http://www.okwusa.com/products/okw/interface-terminal/zoom/zB4146106.jpg [17:22] armin76: ahh [17:22] and i'd prefer a different color instead of white :) [17:25] * Martyn really doesn't bother with cases [17:26] 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] armin76: hehe, you can get, navy blue, fire engine red, explosive yellow, and hot pink [17:27] Martyn: yea that is pretty common [17:28] I do it so the dev boards won't get lost [17:29] hehe indeed [17:30] Martyn: i like to use laminated shelf boards, basically "extra shelf" boards you can buy at most hardware stores [17:31] They are -just- heavy enough that I don't use them [17:31] Generally I either use 5mm (1/4") plywood, or 1/4" ABS cut to size [17:32] 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] HEH! cute :) [17:35] Martyn: i notice you are in the #arduino channel [17:36] Martyn: you done anything with ubuntu on the beagleboard? === nosse1_noob is now known as nosse1 [17:49] re [17:49] 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] prpplague : Yeah, I finished a karmic port .. then moved on to bigger fish [18:08] 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] prpplague: can you share pictures of your 'unused devboards bookshelf'? [18:29] anyone ever build arm-2009q1 from codesourcery native on ubuntu 9.04 ? [18:30] native on arm that is. [18:32] Is there any difference between gcc compiled for ubuntu and the codesourcery (arm-none-linux-gnueabi) when compiling the kernel? [18:32] davilla: may want to ask on #efika about that kind of experiments, not sure if they are using ubuntu or not, though... [18:33] nosse1: you mean vanilla gcc/binutils/glibc contra CSL one? [18:33] i think they do, i may be wrong [18:33] thx, armin76 [18:34] hrw, I'm trying to cross build the kernel and for that I'm using the CSL version [18:34] I remember that theres a kernel option which is to enable the EABI -- I don't know what the alternative is [18:34] nosse1: you don't have crosscompilers on ubuntu afaik [18:34] nosse1: the alternative is OABI :) [18:35] armin76 : Yes there are .. just not for ARM :) [18:35] avr-gcc is an example ... [18:35] nosse1 : For a standard EABI compiler, use the toolchain provided by CodeSourcery [18:35] Martyn: or build own [18:35] It has the latest vfp hard float support, and is an optimized toolchain. the G++ toolchain is free [18:36] I need to recompile the kernel (Ubuntu Lucid), and doing it from qemu chroot takes *ages* [18:36] I hoped I could cross compile it using the CSL one [18:36] 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] Martyn: or use gentoo! :) [18:36] Martyn: I usually do 'bitbake meta-toolchain' and have toolchain built [18:37] * armin76 does crossdev $CHOST [18:37] but thats due to my OE experience [18:37] hrw : It's the source for GCC that's broken (4.4) .. not the crosstools [18:37] Ah, so you're familiar with OE [18:38] 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] hrw, we are trying to decide if we are going to use OE or Debian for our next product [18:38] nosse1: yep, 6 years of using [18:38] nosse1: ubuntu! [18:38] hrw, as you probably have heard from my complaining, I haven't had an easy introduction to ubuntu arm :) [18:38] nosse1: OE gives you automation of building [18:39] Debian/Ubuntu gives you bigger repository of software but also bigger storage requirements [18:39] hrw: what about gentoo! [18:40] 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] armin76: never used [18:40] armin76: as each gentoo build is different from other I prefer to not support it [18:40] we have a total NAND flash of 1G, so ubuntu lucid is fine [18:40] armin76 : gentoo on ARM is a huge PAIN IN THE BUTT [18:40] -heh- [18:41] nosse1: one big ubifs on it? [18:41] build-from-source is not the best way to get customers happy. gentoo is for people who are system performance fetishists :) [18:41] hrw, something like that [18:42] 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] Martyn: if you give customers rootfs + repository of packages they will not see that [18:43] hrw: isn't the same with OE? [18:43] hrw : The way gentoo works, a repository of packages = a repository of source packages. They get compiled every time [18:43] it's not like .ipk's, .deb's, or .rpm's [18:43] But the customer will need upgrades and security fixes, and apt-get fixes that in a very elegant way! [18:43] one of gentoo's base requirements is a full toolchain /must/ exist on the target system [18:43] So my personal choice (from experience with desktop Ubuntu) is to use Ubuntu on this target [18:44] 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] bb in few [18:45]