| === 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_ | ||
| zumbi | Hello guys! Which float-abi was karmic tunned for? | 13:14 |
|---|---|---|
| === fta_ is now known as fta | ||
| markos_ | zumbi: softfp | 13:26 |
| zumbi | markos_: right I found it on the changelog | 13:28 |
| lool | zumbi: jaunty: armv5t, karmic: armv6+vfp(v2), lucid: armv7t2+vfpv3d16 | 13:31 |
| lool | maverick: as luckd | 13:31 |
| lool | *lucid | 13:31 |
| zumbi | I wonder how the benchmarks would do on lucid instead karmic | 13:34 |
| zumbi | lool: I also wonder what this people do with vfp-configure, http://support.eurotech-inc.com/forums/topic.asp?TOPIC_ID=2693 :) | 13:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| lool | markos_: Exactly | 13:48 |
| lool | markos_: And it's kind of obvious to the tester | 13:49 |
| lool | markos_: but really hard to prove | 13:49 |
| 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:50 |
| 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:51 |
| zumbi | lool: sure :) -- it would be nice if you could publish results on them, once you do it | 13:52 |
| * zumbi lunches | 13:53 | |
| lool | zumbi: In general, we try to be as transparent as we can (i.e. fully transparent) | 13:53 |
| 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:54 |
| 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:55 |
| lool | zumbi: Well actually I've heard of some benchmarks used by compilers companies preventing you from publishing results | 13:57 |
| zumbi | :-/ -- anyway we have to be world champions and not only in football :) | 13:59 |
| zumbi | ARM vs Intel | 13:59 |
| lool | Eh | 14:01 |
| 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:09 |
| 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:14 |
| 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:15 |
| Termana | It is rather unfortunate that Lucid is using Thumb-2 though | 14:17 |
| 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:18 |
| lool | rsavoye: serial console? | 14:24 |
| 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:25 |
| rsavoye | the 3 green LEDs are lit, reset doesn't do much | 14:26 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| rsavoye | at least now I know my hardware isn't borked... | 14:35 |
| rsavoye | Wrong Image Format for bootm command | 14:36 |
| 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:37 |
| 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:41 |
| lool | rsavoye: Actually, this might be from anything, what's the full output from your boot? (paste.ubuntu.com) | 14:42 |
| rsavoye | http://paste.ubuntu.com/462063/ | 14:43 |
| rsavoye | can I boot a beagle XM from USB instead of SD/MMC ? | 14:47 |
| === fta_ is now known as fta | ||
| 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:01 |
| 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:10 |
| 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:11 |
| 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:12 |
| rsavoye | still, it should boot with the supplied Angstrom distro | 15:13 |
| lool | rsavoye: Did you order a XM or a C4? | 15:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| rsavoye | I'm adding OpenVG support to Gnash, so I figured I'd also use it for that | 15:19 |
| rsavoye | I see what the problem is, the SD card socket won't let me push the SD card in all the way | 15:34 |
| === fta_ is now known as fta | ||
| === fta_ is now known as fta | ||
| 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:02 |
| rsavoye | at this point I'm hoping I can get the new C4 board I have here working | 17:04 |
| === 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 | ||
| ogra_cmpc | wohoo, zumbi, congrats !!! (that was a hard piece of work) | 22:02 |
| ogra_cmpc | well deserved | 22:02 |
| === fta_ is now known as fta | ||
| lool | suihkulokki: Sent a patch your way for an issue I was seeing with an Angstrom image | 22:49 |
| === fta_ is now known as fta | ||
| === fta_ is now known as fta | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!