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