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