**** BEGIN LOGGING AT Sun Jul 11 02:59:57 2010 Jul 11 12:14:11 Hello guys! Which float-abi was karmic tunned for? Jul 11 12:26:04 zumbi: softfp Jul 11 12:28:39 markos_: right I found it on the changelog Jul 11 12:31:41 zumbi: jaunty: armv5t, karmic: armv6+vfp(v2), lucid: armv7t2+vfpv3d16 Jul 11 12:31:49 maverick: as luckd Jul 11 12:31:51 *lucid Jul 11 12:34:08 I wonder how the benchmarks would do on lucid instead karmic Jul 11 12:35:45 lool: I also wonder what this people do with vfp-configure, http://support.eurotech-inc.com/forums/topic.asp?TOPIC_ID=2693 :) Jul 11 12:36:39 zumbi: I would highly recommend you compare karmic and lucid, lucid is using thumb-2, and I'm sure it makes a significant difference Jul 11 12:37:14 lool: in size, yes, in speed? thumb-2 is said to be ~98% as fast as ARM bytecode Jul 11 12:37:18 zumbi: http://support.eurotech-inc.com/developers/linux/files/tools/vfp-configure seems to be to patch the specs of gcc, very ugly Jul 11 12:37:43 lool: the problem here is that i am stuck on a slow network line :-/ Jul 11 12:37:57 zumbi: The best is to rebuild the toolchain, but otherwise it's much cleaner to use a wrapper to force default flags, or to use the Ubuntu approach to set default flags (doesn't catch all cases) Jul 11 12:38:21 markos_: The catch is that SoCs have a specific cache size Jul 11 12:38:27 Ubuntu approach? Jul 11 12:38:46 markos_: Having smaller code means it might fit in cache and make a huge difference in speed Jul 11 12:38:58 lool: so you did see a difference in speed? Jul 11 12:39:06 got any urls I could check? Jul 11 12:39:06 zumbi: For years, Ubuntu used to set CFLAGS and LDFLAGS in the environment of builds (in dpkg-buildpackage) Jul 11 12:39:21 zumbi: Now this is about to be superseded by dpkg-buildflags, but this will take years to deploy across packages Jul 11 12:39:41 lool: cool idea (dpkg-buildflags that is) Jul 11 12:39:49 markos_: We certainly witnessed differences, but we didn't do any serious benchmark I'm afraid Jul 11 12:39:57 ok Jul 11 12:40:02 Problem is that back then, none of the Ubuntu ARM folks knew what to benchmark Jul 11 12:40:14 Now I could perhaps name a couple of benchmarks Jul 11 12:40:15 lool: but that CFLAGS and LDFLAGS stuff was doko's request to Debian Dpkg a while a go (a couple years ago) Jul 11 12:40:21 but I know that a bunch of benchmarks are private, sadly Jul 11 12:40:37 zumbi: Sorry, I don't get your point Jul 11 12:40:45 lool: for a moment I though Ubuntu had some kind of specific thing :) Jul 11 12:40:55 zumbi: Well Debian doesn't want to implement that Jul 11 12:41:00 it's deemed too ugly Jul 11 12:41:06 at some level, I agree Jul 11 12:41:13 but it did the job :-) Jul 11 12:41:42 markos_: In general, I find it hard to define good benchmarks for Debian/Ubuntu use cases because they are so broad Jul 11 12:42:09 and some things are hard to benchmark even when you think you know what you want to benchnkar Jul 11 12:42:11 lool: http://www.netlib.org/benchmark/ Jul 11 12:42:21 e.g. "I want to benchmark application startup times!" Jul 11 12:42:46 yes of course Jul 11 12:42:50 For instance, what does benchmarking mesa really mean? Jul 11 12:43:12 Say you get 30x better improvement, that doesn't make the whole OS 30x better, nor mesa apps 30x better Jul 11 12:43:15 etc. Jul 11 12:43:24 yes, I totally agree with you Jul 11 12:43:28 now that I talk with toolchain folks regularly, some names popup Jul 11 12:43:46 for speed or for code size Jul 11 12:43:55 improvement varies with the application -or library- and the use case Jul 11 12:44:10 what in one case might prove great might be useless in another Jul 11 12:44:14 zumbi: Thanks; this seems to be a couple of benchmarks with variation? Jul 11 12:44:22 markos_: Absolutely Jul 11 12:44:38 eg. I would prefer a 5% speed increase in one function that gets called 1M times, rather than a 50% speed increase in a function that gets called only once :) Jul 11 12:44:55 eh exactly Jul 11 12:45:09 Which is why thumb2 is such an interesting technology Jul 11 12:45:16 just like this hard-float port Jul 11 12:45:24 yes, had no idea it makes such a big difference Jul 11 12:45:25 lool: the interesting benchmark is whetstone.c for libm test Jul 11 12:45:28 I'll test it later Jul 11 12:45:52 Perhaps I miss some technical details as of the state of gcc and hard-float support, whether it could go bad etc., but it feels to me it's necessary better and will improve by some small percents /all over the place/ Jul 11 12:46:05 zumbi: Ok thanks Jul 11 12:46:05 yes it should Jul 11 12:46:12 zumbi: I remember that for vfp we tried running the python testsuite Jul 11 12:46:24 you know, it takes a while, uses some float from time to time, etc. Jul 11 12:46:36 well there was improvement, but it was really minor Jul 11 12:46:46 (I think we benched when we added libc-vfp) Jul 11 12:46:50 lool: for example, even the plain gnome desktop (karmic) feels *just a bit faster* and is more responsive because of that Jul 11 12:47:24 my guess is that improvements eg in tiny places, make the difference, eg. SVG icon rendering is faster -SVG definitely uses lots of floating point Jul 11 12:47:37 and stuffl like that Jul 11 12:48:54 markos_: Exactly Jul 11 12:49:05 markos_: And it's kind of obvious to the tester Jul 11 12:49:08 markos_: but really hard to prove Jul 11 12:50:19 lool: for the compilers, do you run Polyhedra or SPEC on them? Jul 11 12:50:21 well, in these cases I just quote the official ARM statement "it saves 20 cycles per call :)" Jul 11 12:50:30 (/me alks linaro now) Jul 11 12:50:30 bbl Jul 11 12:51:21 zumbi: ATM nothing, we're too busy fixing bugs :-) Jul 11 12:51:50 zumbi: We discussed building infrastructure to run benchmarks regularly, and I think it will be part of our release procedures, but for now we have more urgent things to finish Jul 11 12:52:06 lool: sure :) -- it would be nice if you could publish results on them, once you do it Jul 11 12:53:17 * zumbi lunches Jul 11 12:53:40 zumbi: In general, we try to be as transparent as we can (i.e. fully transparent) Jul 11 12:54:07 the only reason we might not be in a position to do so, is if the testsuite's license prevents that, or we get hardware with a license to not publish benchmark results Jul 11 12:55:02 lool: yes, I see that and I appreciate you being transparent. While benchmarks are not free, AFAIK nothing prevents you from publishing its results Jul 11 12:55:20 but you are the one that knows better Jul 11 12:55:38 or at least that have the right contacts Jul 11 12:57:48 zumbi: Well actually I've heard of some benchmarks used by compilers companies preventing you from publishing results Jul 11 12:59:06 :-/ -- anyway we have to be world champions and not only in football :) Jul 11 12:59:28 ARM vs Intel Jul 11 13:01:12 Eh Jul 11 13:09:19 so I've got a new Beagle board here that refuses to power up. It worked once till I swapped SD cards Any ideas ? Jul 11 13:09:56 lool: don't worry about benchmarks, phoronix are quite good at comparing every OS on the planet every week :) Jul 11 13:14:27 well look at that... Jul 11 13:14:35 I just tried -mthumb on some Eigen benchmark Jul 11 13:14:41 (hardfp) Jul 11 13:14:56 and I get an extra 0.1GFLOPS with -mthumb enabled Jul 11 13:15:05 0.83GFLOPS vs 0.73 Jul 11 13:15:12 that's a big difference Jul 11 13:15:35 no doubt because there is a more space in the cache to reserve for the data Jul 11 13:17:38 It is rather unfortunate that Lucid is using Thumb-2 though Jul 11 13:18:28 Thumb-2 support is broken on OMAP3430 AFAIK (what's inside the n900 - so we can't really use Lucid) Jul 11 13:18:50 (we = n900 owners that is) Jul 11 13:24:53 rsavoye: serial console? Jul 11 13:25:02 rsavoye: Does it say anything? Jul 11 13:25:11 I get nothing from the serial console Jul 11 13:25:33 it booted up once with Angstrom, then I put in an SD card with Lucid on it, now I get zilch.. Jul 11 13:26:01 the 3 green LEDs are lit, reset doesn't do much Jul 11 13:29:27 rsavoye: This aint good; the serial console should always display something Jul 11 13:29:32 rsavoye: Since the ROM outputs to serial Jul 11 13:29:55 that's what I figured... /dev/USB0 115200 baud ? Jul 11 13:30:06 I use: screen /dev/ttyUSB* 115200 Jul 11 13:30:31 rsavoye: check you dont have multiple /dev/ttyUSB*, can happen on older kernels Jul 11 13:30:48 this is on a Maverick-x86 host Jul 11 13:30:52 rsavoye: BTW doko's internet was borken end of last week, so I failed to chat with him, will do tomorrow I hope Jul 11 13:31:02 rsavoye: Ok; check nevertheless Jul 11 13:31:11 I had races in some conditions in the past, best to double check Jul 11 13:31:25 I just figured I'd get this thing up and running now that I'm back in town Jul 11 13:32:10 Good idea Jul 11 13:32:20 rsavoye: Also, try unplugging replugging the USB serial adapter Jul 11 13:32:34 It happens that its serial port state gets confused by random data with mine Jul 11 13:32:40 ah, got the serial console working this time Jul 11 13:32:51 RROR: can't get kernel image! Jul 11 13:33:02 maybe I need to reset the SD card better.... Jul 11 13:33:30 interestingly, kermit worked fine, minicom didn't Jul 11 13:33:43 rsavoye: Using serial to upload kernels is terribly slow Jul 11 13:33:55 rsavoye: consider writing them to a FAT partition on the SD and loading them from there Jul 11 13:34:26 rsavoye: mmc init, or mmcinit if you have an old u-bot, and fatload mmc 0 0xsomeaddress uImage, then nand write Jul 11 13:34:40 that's how I started, following the directions to boot the Lucid netinstall Jul 11 13:35:18 at least now I know my hardware isn't borked... Jul 11 13:36:37 Wrong Image Format for bootm command Jul 11 13:37:13 rsavoye: Are you trying to push a zImage? Jul 11 13:37:18 rsavoye: You want an uImage for u-boot Jul 11 13:37:28 rsavoye: mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Ubuntu Kernel" -d zImage uImage Jul 11 13:37:36 right now I'm just trying to get the original Angstrom SD to boot Jul 11 13:41:09 hum, I get a No MMC card found Jul 11 13:41:47 rsavoye: Try a second time Jul 11 13:41:54 rsavoye: check that it's properly inserted too Jul 11 13:42:16 rsavoye: Actually, this might be from anything, what's the full output from your boot? (paste.ubuntu.com) Jul 11 13:43:17 http://paste.ubuntu.com/462063/ Jul 11 13:47:41 can I boot a beagle XM from USB instead of SD/MMC ? Jul 11 14:01:03 I have this suspicion my beagle has stopped reading *any* MMC or SD card Jul 11 14:01:40 I can't even get it to upgrade uboot Jul 11 14:10:38 rsavoye: It's not unusual to have compatibility issues with MMC Jul 11 14:10:57 rsavoye: it would be quite surprizing that a brand new board wouldn't take big brand cards though Jul 11 14:11:19 rsavoye: Do buy decent quality SDs, e.g. SanDisk; I don't have a finite list, but have prior bad experience with no name or cheap SDs Jul 11 14:11:28 Oh you have a XM? Jul 11 14:11:34 rsavoye: How did you get it? :-) Jul 11 14:11:46 rsavoye: I dont know what the XM boots from I'm afraid Jul 11 14:12:15 That doesn't look like an XM Jul 11 14:12:27 It says C4 Jul 11 14:12:30 I bought the SDm cables, and beagle from Special Computing Jul 11 14:12:36 Ok Jul 11 14:12:51 it doesn't to me either, I noticed the DRAM was 256, when it should be 512 Jul 11 14:13:26 still, it should boot with the supplied Angstrom distro Jul 11 14:13:48 rsavoye: Did you order a XM or a C4? Jul 11 14:14:01 an XM is what I ordered Jul 11 14:14:17 looking through the purchase order now.... Jul 11 14:14:28 ah, I see it, it *is* a C4, shit. Jul 11 14:14:47 guess I get to see if I can swap it :-( Jul 11 14:15:08 I'm positive I ordered the XM, guess something went wrong Jul 11 14:15:17 rsavoye: It's probably not bad luck Jul 11 14:15:23 rsavoye: XM has unknown ETA to delivery Jul 11 14:15:27 they announce 6 weeks + Jul 11 14:15:49 It's kind of sad to get a C4 at this point, but to work *now* it's best Jul 11 14:16:10 if it works at ll, I can use it, but sure thought I was ordering the XM Jul 11 14:16:30 I'll call Special Computing tomorrow and see whats up Jul 11 14:16:40 when's the Panda coma out ? Jul 11 14:17:01 rsavoye: panda sounds like it's later this year Jul 11 14:17:05 as in August+ Jul 11 14:17:14 rsavoye: I wouldn't count on it to start work now Jul 11 14:17:19 bummer. is the C4 ok for development ? Jul 11 14:17:28 Plus, it will be out of stock for weeks after the launch Jul 11 14:17:30 rsavoye: Sure Jul 11 14:17:39 rsavoye: it should work, I built gcc-4.4 on it Jul 11 14:17:46 rsavoye: You should have decent CPU speed Jul 11 14:17:47 then if I get it to work I can wait for something better Jul 11 14:17:49 rsavoye: the main issue is RAM Jul 11 14:18:00 and it requires a bunch of accessories Jul 11 14:18:03 but the refusal of it to read the MMC is an issue Jul 11 14:18:38 ah, I see the special computing web site has the XM as "pre-order" Jul 11 14:18:46 Yup Jul 11 14:19:19 I'm adding OpenVG support to Gnash, so I figured I'd also use it for that Jul 11 14:34:00 I see what the problem is, the SD card socket won't let me push the SD card in all the way Jul 11 16:02:32 rsavoye: Looks like the Xm had memory issues prior to launch. http://beagleboard.org/buyxM Jul 11 16:02:49 Says they expect to ramp by eom. Jul 11 16:04:16 at this point I'm hoping I can get the new C4 board I have here working Jul 11 21:02:17 wohoo, zumbi, congrats !!! (that was a hard piece of work) Jul 11 21:02:39 well deserved Jul 11 21:49:15 suihkulokki: Sent a patch your way for an issue I was seeing with an Angstrom image **** ENDING LOGGING AT Mon Jul 12 02:59:57 2010