| === Martyn is now known as Berstrom | ||
| === Berstrom is now known as Martyn | ||
| === ogra_ is now known as ogra | ||
| saeed | lool | 12:19 |
|---|---|---|
| saeed | ogra | 12:19 |
| armin76 | saeed | 12:32 |
| saeed | hi armin | 12:35 |
| lool | saeed: Hey | 13:22 |
| saeed | as you know, the suspend button worked for me | 14:18 |
| saeed | but when I convert it to KEY_POWER , and configure the g-p-m to "Ask Me" when power pressed | 14:19 |
| saeed | nothing happens | 14:19 |
| saeed | when I configure the g p m to suspend when power pressed, it works | 14:20 |
| persia | saeed: So, g-p-m is capturing your button press, but not launching the GUI when configured to "Ask Me"? | 14:45 |
| lool | saeed: In a terminal, killall gnome-power-manager and then run gnome-power-manager --verbose | 15:06 |
| lool | saeed: That should give you some debugging info on what GPM is seeing | 15:06 |
| saeed | persia yes exactly | 15:52 |
| therealgalen | What is everybody using to build for ARM? Are there particular compilers that are optimized for ARM? | 16:08 |
| armin76 | codesourcery's | 16:09 |
| therealgalen | armin76: fastest? | 16:12 |
| persia | therealgalen: We use native compilation in Ubuntu: compiling ARM on ARM. | 17:07 |
| therealgalen | persia: I don't mean the hardware so much as the software - the compiler | 17:29 |
| therealgalen | a lot | 17:29 |
| therealgalen | of vendors claim to have "faster" or "better" compilers | 17:29 |
| persia | Ah. I don't think Ubuntu claims faster or better, but I know a lot of work has gone into making it appropriate for ARMv7+Thumb2 | 17:30 |
| persia | But no special secret sauce: most of the changes are upstream, so I suspect anyone could grab them if they felt it was a competition. | 17:31 |
| * persia is more concerned about making the software work than about the compiler being especially fast | 17:31 | |
| therealgalen | persia: architecture-specific issues, or just general development? | 17:32 |
| persia | Both :) | 17:32 |
| persia | Although a lot of what I personally do is actually neither, but rather just things like improving developer tools to make it easier to do those, or reviewing cases where something didn't build for reasons involving how the distribution is developed, etc. | 17:33 |
| therealgalen | well, i am looking at a variety of companies offering gcc alternatives claimed to be faster; i was hoping to hear from people who have tried them | 17:36 |
| armin76 | therealgalen: its known to be the most optimized, yes | 17:40 |
| therealgalen | armin76: are there any benchmarks *not* from the vendor online? | 17:41 |
| persia | armin76: optimised for which? execution time, code size, compilation time, etc.? | 17:42 |
| * persia is fairly certain it's not possible to optimise for those three things simultaneously, and suspects there are other similar variables. | 17:42 | |
| therealgalen | execution performance primarily; compilation time does not matter, code size does not matter | 17:43 |
| armin76 | persia: no clue, its just what they tend to say | 17:47 |
| armin76 | persia: in fact they tend to say that vanilla gcc sucks | 17:47 |
| armin76 | therealgalen: no clue, sorry | 17:47 |
| persia | therealgalen: From what I understand, it really depends on which code you need so optimised. | 17:48 |
| persia | Try a few different toolchains, and see which one compiles your application in the fastest way. | 17:49 |
| therealgalen | hmm, ok | 17:53 |
| therealgalen | persia: most of the functions are kernel stuff, ath9k, ec. | 17:53 |
| persia | The kernel gets kinda fussy about opimisation. Generally, I think it's better to walk the code path and optimise in code than try to adjust toolchains for that class of issues. | 17:54 |
| persia | Just because the kernel code makes some assumptions about how it will be compiled. | 17:54 |
| DanaG | oh heya, where do I get the ARM toolchain for cross-compiling stuff? | 19:35 |
| DanaG | apt-cache search gcc doesn't show anything related to ARM. | 19:35 |
| persia | We don't cross-compile :) | 19:36 |
| persia | we just rebuilt everything natively. | 19:36 |
| DanaG | How'd you get the first one up, then? =þ | 19:37 |
| persia | Used Debian's compilation. | 19:37 |
| armin76 | they stole it :D | 19:37 |
| * persia prefers to think of it as "sharing" | 19:37 | |
| * DanaG wishes somebody would make something like that "touchbook" but with the new Marvell 1.2GHz thingy. | 19:53 | |
| DanaG | The worst embedded thing I've ever (tried to) use: Microblaze. It was so bad, that building the cross-compiler made the HOST compiler segfault! | 19:56 |
| DanaG | hmm, what systems do you run the armel compilation on? | 20:04 |
| persia | I'm not sure precisely. I suspect there's at least one package that shows it in the build log, but :) | 20:06 |
| persia | I do know that they are ARMv7 machines. | 20:06 |
| persia | Personally, I do test-compilation on a Sharp Netwalker, but we only upload sources. | 20:07 |
| DanaG | Oh yeah, worst distro fail I've ever seen was Angstrom on a Zaurus SL-5500. I can understand drivers not working... but to have your kernel config for that board not enable the ALREADY-IN-KERNEL drivers for that board? That's just epic fail. | 20:13 |
| DanaG | I wish I could get Ubuntu running on the thing. | 20:13 |
| persia | The 5500? That's too old. | 20:16 |
| persia | Jaunty should run on the 1000, 1100, 3000, 3100, 3200, and 3300 | 20:16 |
| persia | But karmic or lucid won't. | 20:16 |
| DanaG | My gripe was that they discontinued OpenZaurus in favor of the supposedly superior "Angstrom" -- but then seemingly didn't even TRY to make the old hardware work. | 20:18 |
| DanaG | Having it work slowly and poorly... fine.... but disabling in-kernel touchscreen driver? fail. | 20:19 |
| DanaG | Anyway, now I'm using a beagleboard, and that's cool. | 20:19 |
| persia | Well, Sharp discontinued the device, which may have had something to do with that. | 20:19 |
| persia | You're running lucid on your beagleboard? | 20:19 |
| DanaG | Yeah. | 20:20 |
| DanaG | Still, they could've at least set CONFIG_UCB1100_TS true, or whatever that was. | 20:20 |
| DanaG | anyway, enough bashing Angstrom. | 20:20 |
| DanaG | I'm using Ubuntu on it because it'll be just like my main development environment. | 20:20 |
| DanaG | Too big for the onboard flash, though -- I'm using a 2-gig SD card. | 20:20 |
| DanaG | hmm, is there anything useful I COULD use the onboard flash for? | 20:21 |
| persia | I think we still need a slightly better way to dispatch test-builds to other machines though. I have to manually scp sources to armel or powerpc devices from my laptop to build them. | 20:21 |
| persia | But other than that, I think it works just fine. | 20:21 |
| persia | How big is the onboard flash? | 20:21 |
| DanaG | I think it's just 256 megs. | 20:22 |
| armin76 | i didn't know the bb had internal flash | 20:22 |
| DanaG | And u-boot takes up some of that. | 20:22 |
| persia | That's tight. You might be able to stuff your kernel and initramfs in there. | 20:23 |
| persia | But I don't think you can do anything advanced with it. | 20:23 |
| DanaG | Might as well just leave it on initramfs. | 20:23 |
| DanaG | now, this would be cool, if not for the tiny battery: http://eeepc.net/superthin-netbook-runs-on-marvell-armada-510/ | 20:24 |
| DanaG | Oh yeah, I did have a lot of trouble getting the usb host-to-device networking working.... it was encoding the packets badly (off-by-one error). | 20:26 |
| persia | Nobody seems to want to put a full-size battery in with a low-power device. I really wouldn't mind an extra 100g for an extra 10 hours of power. | 20:26 |
| DanaG | yeah, that sucks. | 20:27 |
| DanaG | My network issue: I set guest device to mac address 00:11:22:33:44:55, and the parent saw "Ethernet II" frames from address ff:ff:00:11:22:33 sending packets of type 4455. | 20:27 |
| persia | Well, it probably also costs an extra 12,000円 for that extra 100g, which makes it perceived as less competitive. | 20:27 |
| DanaG | What currency unit is that? | 20:28 |
| persia | Wah! That's just not right :) | 20:28 |
| DanaG | I finally fixed it by passing g_ether.use_eem=0 | 20:28 |
| persia | Oh, right. That gets used in multiple contexts. JPY is what I was thinking. | 20:28 |
| DanaG | then it used full cdc-ether instead of cdc-subset. | 20:28 |
| jonnor | Hi. What libc implementation is being used in Ubuntu ARM? | 20:32 |
| armin76 | windows! | 20:32 |
| armin76 | jonnor: eglibc | 20:33 |
| jonnor | armin76: cool, thanks! | 20:34 |
| DanaG | heh, note to self: ext4 as root on flash means I can't use ext2load. | 20:35 |
| === DanaG1 is now known as DanaG | ||
| DanaG | init: ureadahead main process (41) terminated with status 5 mountall: Could not connect to Plymouth init: procps main process (369) terminated with status 255 init: ureadahead-other main process (466) terminated with status 4 | 21:12 |
| DanaG | that's on the beagleboard. | 21:12 |
| ogra | seems your kernel misses a good bunch of options and plymouth isnt installed | 21:29 |
| ogra | none of these issues should stop it from finishing the boot though | 21:31 |
| * ogra goes back to weekendish stuff | 21:32 | |
| DanaG | init: ureadahead main process (40) terminated with status 5 | 21:34 |
| DanaG | oh yeah, I don't plan to use the video output for much (at least for now), anyway. | 21:35 |
| DanaG | Also weird: the default user's named group is not 1000 like it is on the host system. | 21:35 |
| DanaG | beagleboard has this: | 21:39 |
| DanaG | mtdparts: mtdparts=nand:512k(x-loader),1920k(u-boot),128k(u-boot-env),4m(kernel),-(fs) | 21:39 |
| === asac_ is now known as asac | ||
| DanaG | !find pkg-config | 22:40 |
| ubot4 | DanaG: Found: pkg-config | 22:40 |
| DanaG | =þ | 22:40 |
| DanaG | odd that command-not-found doesn't seem to work on ARM. | 22:40 |
| DanaG | !find dbus-glib-1 | 22:51 |
| ubot4 | DanaG: Found: libdbus-glib-1-2, libdbus-glib-1-2-dbg, libdbus-glib-1-dev, libdbus-glib-1-doc | 22:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!