• [00:28:03] * zodttd (n=recompil@user-142gtg7.cable.mindspring.com) has joined #beagle
  • [00:28:28] <zodttd> Does the EVM support RGB555 or BGR555?
  • [00:39:02] <zodttd> I'm also looking into the use of VFP/Neon instruction sets
  • [02:50:17] * Crofton (n=balister@86-42-199-64.b-ras1.cld.dublin.eircom.net) Quit (Success)
  • [02:58:56] * Crofton (n=balister@86-42-199-64.b-ras1.cld.dublin.eircom.net) has joined #beagle
  • [03:45:41] * BThompson (n=BThompso@cpe-76-185-66-252.tx.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
  • [04:37:54] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [04:38:09] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) has joined #beagle
  • [04:40:02] * JoeBorn (n=jborn@cpe-66-1-5-91.il.sprintbbd.net) Quit (Read error: 110 (Connection timed out))
  • [04:47:20] * jkridner|wor1 (n=a0321898@nat/ti/x-d95fd9d43f589c70) has joined #beagle
  • [04:51:10] * jkridner|work (n=a0321898@nat/ti/x-f755ed875c1b2847) Quit (Remote closed the connection)
  • [05:08:29] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [05:08:58] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) has joined #beagle
  • [05:47:43] <zodttd> <jkridner|work> 2.6.26-rc1-omap1!
  • [05:47:54] <zodttd> Ouh! Sounds good to me. :)
  • [06:03:20] <jkridner> I was congratulating koen on getting DVI output on the git kernel.
  • [06:03:58] <jkridner> I'm not sure what the order of the pixels are on the EVM framebuffer.
  • [06:04:06] <jkridner> did you test to see?
  • [06:04:19] <jkridner> I'd guess RGB.
  • [06:04:27] <zodttd> By default its RGB565 (16bit)
  • [06:04:45] <jkridner> I believe RGB888 is supported as well.
  • [06:05:04] <zodttd> Yes. Makes sense.
  • [06:05:15] <zodttd> Was just wondering...
  • [06:05:29] * jkridner yawns. 1AM. Time for sleep.
  • [06:05:34] <jkridner> yeah?
  • [06:05:43] <jkridner> what do you wonder?
  • [06:05:46] <zodttd> oh, nothing...
  • [06:05:51] <zodttd> bad phrasing :P
  • [06:06:04] <jkridner> oh, earlier.
  • [06:06:24] <zodttd> Yeah. Get some rest, I'll bother ya about all these Linux distros tommorow. ;P
  • [06:06:31] <jkridner> do you have the User's Guide handy?
  • [06:06:35] <zodttd> Yup
  • [06:07:06] <zodttd> The Hardware User Guide at least
  • [06:07:09] <jkridner> That's where I'd end up looking. :)
  • [06:07:16] <jkridner> There is a S/W User's Guide as well.
  • [06:07:28] <zodttd> Oh I dont believe I have that on me currently...
  • [06:07:34] <jkridner> In addition to the Getting Started Guide.
  • [06:07:38] <zodttd> That would explain some things.
  • [06:07:54] <zodttd> Getting Started is one of the ones I have
  • [06:08:05] <jkridner> UserGuide_0_9_5.pdf
  • [06:08:15] <zodttd> :( nope
  • [06:08:43] <jkridner> It is inside the .bin file.
  • [06:08:51] <zodttd> aha! ok
  • [06:08:59] <zodttd> I should have it then
  • [06:09:18] <jkridner> Section 4 is the Video Driver.
  • [06:09:42] <jkridner> Talks about how to enable rotation.
  • [06:09:53] <zodttd> Great. Once I tackle that, I'll move on to NEON and VFPU
  • [06:10:00] <jkridner> I tried it and it didn't work for me, but I believe it'll be fixed in the next rev.
  • [06:10:06] <zodttd> Yeah
  • [06:10:12] <zodttd> I tried to enable it as well
  • [06:10:18] <zodttd> No luck on my end either
  • [06:11:22] <jkridner> Next release is about 1 week away (btw).
  • [06:11:41] <zodttd> Great to hear. Simple upgrade? ;)
  • [06:11:48] <jkridner> bad block management for the OneNAND is the primary update.
  • [06:12:06] <zodttd> Anything about the TWL timing out?
  • [06:12:08] <jkridner> well, I'm not sure if clean patches will be provided.
  • [06:12:15] <zodttd> ah ok
  • [06:12:25] <jkridner> If you aren't hacking the kernel, then it is just a new version.
  • [06:12:39] <jkridner> no additional H/W docs as part of the upcoming S/W release.
  • [06:13:18] <zodttd> Thats ok. Though I like to keep up to date with such. Especially if it affect performance any.
  • [06:14:10] <jkridner> I'm off to sleep. Let me know later if you cannot find UserGuide_0_9_5.pdf.
  • [06:14:17] <zodttd> Ok will do
  • [06:14:20] <zodttd> Night :)
  • [06:14:25] <jkridner> night!
  • [06:14:57] <zodttd> found it ;)
  • [08:16:19] * ldesnogu (n=ldesnogu@ven06-2-82-247-86-183.fbx.proxad.net) has joined #beagle
  • [08:16:24] <ldesnogu> hello
  • [08:41:24] <koen> hey ldesnogu
  • [08:59:05] <ldesnogu> Funny, TI is putting many wiki's online :)
  • [09:01:06] <ldesnogu> koen: the lmbench you ran a few days ago, was run with what frame buffer size and depth?
  • [09:02:48] <koen> no framebuffer afaik
  • [09:03:38] <ldesnogu> would it be difficult or a pain for you to re-run it with the max FB size that works?
  • [09:04:12] <koen> no, not at all
  • [09:04:23] <koen> 1024x768x16bpp currently
  • [09:04:38] <ldesnogu> fine :)
  • [09:08:43] <ldesnogu> I am very surprised by the 250 MB/s read BW
  • [09:09:27] <ldesnogu> and since sakoman got the same, it looks like that result can be trusted
  • [09:11:20] <koen> running lmbench on 2.6.26rc1 now
  • [09:11:49] <ldesnogu> look at these results: http://www.gp32x.com/board/index.php?s=&showtopic=30759&view=findpost&p=543462
  • [09:12:21] <ldesnogu> hum forget that link :)
  • [09:12:40] <ldesnogu> didn't notice this: "Note those are best-case figures (more or less). Different sizes give lower numbers."
  • [09:13:31] <koen> memcpy in libc is pretty wel optimized for arm
  • [09:14:00] <ldesnogu> while in newlib it's useless ;)
  • [09:14:13] * koen refrains from commenting on newlib
  • [09:14:39] <ldesnogu> is the memcpy in the glibc you have using pld?
  • [09:15:03] <koen> haven't looked
  • [09:15:15] <ldesnogu> where does it come from? CSL?
  • [09:15:16] <koen> nico and/or pb_ wrote it
  • [09:15:55] <ldesnogu> I meant where does the binary you use come from
  • [09:18:17] <koen> ldesnogu: http://amethyst.openembedded.net/~koen/beagleboard/lmbench.results.2.6.26rc1.20080511.txt
  • [09:18:25] <koen> ldesnogu: compiled it myself :)
  • [09:18:37] <ldesnogu> with armv6/7 flag?
  • [09:18:45] <koen> armv7a flags
  • [09:19:08] <koen> but it's optimized for armv5te, so I don't think that would make a big difference
  • [09:19:34] <ldesnogu> your results show a 10% decrease for both R and W (IIRC your previous results)
  • [09:20:20] <koen> the first run was with the TI wtbu kernel
  • [09:20:30] <koen> the current one with linux-omap-git
  • [09:21:18] <ldesnogu> well a decrease is expected since your FB is stealing bandwidth
  • [09:21:41] <koen> .22 also has the fb turned on (I realize now)
  • [09:21:47] <ldesnogu> and the only place where the kernel could change lmbench results for BW would be in ram settings
  • [09:22:04] <ldesnogu> ouch...
  • [09:22:11] <ldesnogu> then that doesn't look good :(
  • [09:23:18] <koen> pesonally, I can live with 10% less if all code is upstream
  • [09:24:06] <koen> it would be nice to find out where that 10% is coming from, though
  • [09:27:51] <ldesnogu> even better it would be nice to find why the read BW is that low
  • [09:28:33] <ldesnogu> the A8 should have a higher bandwidth
  • [09:29:20] <koen> could it be that we're using slow memory?
  • [09:29:26] <koen> 116MHz mddr iirc
  • [09:29:45] <ldesnogu> I was told 166 MHz with 32 bit wide bus
  • [09:29:46] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [09:29:58] <koen> yeah 116 was a typo
  • [09:30:15] <ldesnogu> that translates into 1328 x 10^6 theoretical BW
  • [09:31:28] <like2wise> gm
  • [09:31:32] <ldesnogu> and just in case you wonder I reached theoretical BW on my PC with DDR running lmbench, so it's probably not some lmbench inefficiency
  • [09:31:35] <ldesnogu> hello
  • [09:31:43] <koen> hey like2wise
  • [09:48:57] <zodttd> I was reading up on NEON...I'm currently using the 2007q3 release of CodeSourcery's toolchain, will "-mfpu=neon -mfloat-abi=softfp -ftree-vectorize" have any effect in the code it generates, or is it not enabled in this revision?
  • [09:49:31] <ldesnogu> why don't you use 2088q1?
  • [09:49:38] <ldesnogu> 2008q1 :)
  • [09:49:40] <zodttd> Not sure to be honest
  • [09:49:49] <zodttd> I was told to use 2007q3
  • [09:50:00] <zodttd> Though I cant remember why
  • [09:51:16] <ldesnogu> I don't remember when NEON vectorization was added
  • [09:52:18] <zodttd> hmm, well 2007q3 compiles with it, though I wasnt sure if it really implemented things...
  • [09:52:29] <ldesnogu> if you want to check if your compiler is able to vectorize NEON try some very simple loop such as vector add
  • [09:53:08] <koen> I'm curious about benchmarks between -mfpu=vfp and -mfpu=neon -ftree-vectorize
  • [09:53:09] <zodttd> I've just now figured out the list of NEON instructions
  • [09:53:32] <koen> zodttd: http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html
  • [09:53:40] <ldesnogu> zodttd: I have put a link on the Pandora wiki for instruction descriptions ;)
  • [09:54:11] <ldesnogu> and it's also on Beagle elinux page
  • [09:54:20] <ldesnogu> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Bcfjicfj.html
  • [09:54:27] <zodttd> koen: I noticed no speedups going from no -mfpu define to -mfpu=neon etc in my emulator. Was thinking it could just be a poor test
  • [09:54:34] <zodttd> Aha
  • [09:54:38] <zodttd> Didnt see the first link
  • [09:56:05] <zodttd> Awesome, that should help heaps
  • [09:56:36] <ldesnogu> zodttd: IIRC NEON only does single precision floating point
  • [09:56:45] <ldesnogu> (remove the IIRC :p)
  • [09:56:55] <koen> ldesnogu: http://amethyst.openembedded.net/~koen/beagleboard/ARM-VFP-NEON.pdf :)
  • [09:57:09] <ldesnogu> the VFP is not pipelined, while NEON is
  • [09:57:21] <ldesnogu> so one should always use NEON for FP on Cortex-A8...
  • [09:57:51] <ldesnogu> koen: you are missing all the subsequent chapters :D
  • [09:58:10] <koen> ldesnogu: looking on the internets I have a slightly different opinion on what people should use
  • [09:58:20] <ldesnogu> ?
  • [09:58:21] <koen> 1) stop trying to download random packages from 2001
  • [09:58:26] <koen> 2) use EABI
  • [09:58:32] <koen> 3) use hardfloat
  • [09:58:45] <koen> most users fail at step one or two.....
  • [09:58:50] <ldesnogu> :)
  • [09:59:02] <ldesnogu> step 2 implies step 1
  • [09:59:13] <koen> so "vfp/eabi" is already going to give most people more OMG!!!
  • [09:59:45] * koen removes CONFIG_OABI_COMPAT whenever he can from defconfigs
  • [10:00:19] <ldesnogu> well I agree, but I like to push things the most I can, and during the process I forget people don't necessarily know the other steps :(
  • [10:01:29] <koen> some weeks ago some vendor announced an "open hackable phone" with 2.4.21
  • [10:01:47] <koen> the ceo still thinks 2.4 is the best thing next to sliced bread
  • [10:02:00] <koen> he didn't even know that 2.4 doesn't have arm support at all
  • [10:02:17] <ldesnogu> :p
  • [10:04:27] <ldesnogu> zodttd: for your vectorize tests, you might need -ffast-math
  • [10:05:29] <koen> and -noatime
  • [10:05:32] * koen hides
  • [10:05:52] * ldesnogu wonders what noatime is
  • [10:05:57] <zodttd> me too
  • [10:06:00] <zodttd> I just asked Exophase heh
  • [10:07:12] <koen> heh, I take you haven't read http://funroll-loops.info/
  • [10:07:57] <ldesnogu> :D
  • [10:08:42] <ldesnogu> I don't feel concerned, my day job is benchmarking ;)
  • [10:08:57] <ldesnogu> so yes I overtune
  • [10:09:01] <koen> yeah
  • [10:09:07] <koen> I love benchmarks
  • [10:09:21] <ldesnogu> dhyrstone is so sweet
  • [10:09:25] <koen> I keep asking people to prove that -OMG is better than -ROFL
  • [10:09:55] <koen> It only took 2 years before someone proved that iwmmxt (on xscales) can make a difference
  • [10:09:56] <ldesnogu> I love the picture at the end
  • [10:10:22] <ldesnogu> does jkridner know that page? :p
  • [10:10:30] <koen> most iwmmxt advocated enabled the video overlay at the same time and said "see, better media performance"
  • [10:11:02] <zodttd> heh
  • [10:11:03] <koen> I don't have much against gentoo
  • [10:11:30] <zodttd> The whole SRAM/overlay stuff was so confusing to most (including me)
  • [10:11:51] <ldesnogu> the ARM applications need tuning in general
  • [10:11:54] <koen> actually it is sram/overlay/iwmmxt even :)
  • [10:12:05] <zodttd> heh
  • [10:13:04] <koen> and "resizing from vga -> qvga"
  • [10:13:11] <koen> and then people started overclocking
  • [10:13:15] <zodttd> ugh
  • [10:13:15] <ldesnogu> zodttd: don't forget -mcpu=cortex-a8
  • [10:13:16] <zodttd> yes
  • [10:13:36] <zodttd> ldesnogu: aha I did forget that. I should assume the specs are decent
  • [10:13:51] <ldesnogu> you mean there are people overclock their OMAP's? :p
  • [10:13:58] * zodttd whistles
  • [10:14:14] <zodttd> He was referring to the Zaurus I believe
  • [10:14:22] <zodttd> But I OC'd my EVM to 900MHz stable
  • [10:14:51] <zodttd> 925 "works" but eventually will crash
  • [10:16:04] <zodttd> ldesnogu: Did you get a EVM?
  • [10:16:29] <koen> The beagle at 900MHz would be sweet
  • [10:16:29] <zodttd> ldesnogu: Was wondering how you did the lmbench's :P
  • [10:16:57] <ldesnogu> I don't have any Cortex-A8 stuff, except for some HW emulator at work :D
  • [10:17:15] <zodttd> koen: All it takes is a bump of voltage to vdd1, and a few writes to some hw regs
  • [10:17:52] <zodttd> I have some binaries and source for overclocking, and I just set the vdd1 voltage via echo 5 >/sys/power/...
  • [10:18:21] <koen> the power stuff isn't in linux-omap-git yet AFAIK
  • [10:18:52] <zodttd> So exactly what have you been working on? OE on the Beagle?
  • [10:19:20] <koen> Angstrom on the beagle is working already, that was like 5 minutes of work :)
  • [10:19:32] <zodttd> So whats left?
  • [10:19:35] <koen> I have been copy-pasting EVM patches to get stuff working with the omap git kernel
  • [10:19:38] <zodttd> Err yes, Angstrom :P
  • [10:19:52] <zodttd> git kernel?
  • [10:20:00] <ldesnogu> zodttd: I am just learning
  • [10:20:28] <koen> zodttd: http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=shortlog
  • [10:20:35] <zodttd> checking
  • [10:21:06] <zodttd> ldesnogu: So am I :)
  • [10:21:22] <zodttd> ldesnogu: As well as writing some emu stuff
  • [10:21:23] <zodttd> heh
  • [10:21:33] <koen> 2.6.22 is almost a year old now
  • [10:21:59] <zodttd> koen: Aha! So whats the difference between EVM default distro -> Angstrom -> omap-git ?
  • [10:22:18] <zodttd> 3 seperate projects?
  • [10:22:20] * ldesnogu pick some popcorn
  • [10:22:20] <koen> you can run whatever kernel you like with the angstrom distro
  • [10:22:42] <koen> I run the .22 kernel from time to time to check things without problems
  • [10:23:02] <zodttd> Aha
  • [10:23:19] <koen> angstrom gives you a root filesystem that is reasonably optimized for the cpu and a shitload of packages you can easily install
  • [10:23:49] <ldesnogu> zodttd: I have checked the vectorizer works with NEON for some simple loops
  • [10:23:49] <koen> and OE makes it easy to build packages that are entirely optimized for the cpu
  • [10:23:56] <zodttd> I'm currently using the EVM in the state given to me, with a JFFS2 filesystem
  • [10:24:04] <zodttd> ldesnogu: Awesome!
  • [10:25:24] <koen> I can understand TI wants to develop their .22 kernel, but for me linux-omap is a better choice, because I can see the development and can easily push fixes upstream
  • [10:25:28] <ldesnogu> note it was with an pre-release of 2008q1
  • [10:25:36] <zodttd> I'm not really looking for features/packages other than raw performance of my emulator at the moment. Since DJWillis is working on getting things up and running, I am just trying to see how fast I can push my software
  • [10:26:14] <ldesnogu> zodttd: did you check the FB is mapped as a 1 MB section in ARM MMU?
  • [10:26:22] <ldesnogu> that could help *a lot*
  • [10:26:25] <zodttd> I wonder which direction DJWillis will take with the distro for Pandora
  • [10:26:33] <zodttd> ldesnogu: Wa waaa what?
  • [10:26:43] <zodttd> I can check now
  • [10:26:58] <koen> zodttd: but having an nice package for your emu that people can simply upgrade with "opkg upgrade" would be a big plus
  • [10:27:01] <ldesnogu> it's not easy to check...
  • [10:27:36] <zodttd> koen: Currently whatever distro we choose is being dealt with by DJWillis.
  • [10:28:07] <koen> ldesnogu: isn't that a kernel config option?
  • [10:28:31] <ldesnogu> is it?
  • [10:28:44] <ldesnogu> if so that's really great!
  • [10:29:01] <zodttd> So without a chosen distro that I know of that will be used, I'm just aiming for raw performance and learning the ins and outs.
  • [10:29:07] <koen> CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=4
  • [10:29:27] <zodttd> Hmm what does the stock EVM .22-omap1 use?
  • [10:29:44] <koen> zodttd: I was trying to say that you, as a developer shouldn't care about distros and packages
  • [10:29:55] <koen> zodttd: let other people handle that part :)
  • [10:30:22] <zodttd> I should, but im impatient and tend to help wherever I can
  • [10:30:27] <zodttd> ;P
  • [10:32:04] <zodttd> distros I shouldnt care as much about, until I cant use things that should be provided. For instance I would like to rotate the framebuffer which is currently not working this revision of the distro.
  • [10:32:57] <zodttd> So if the distro can provide things that I can mark down as being helpful to me, I can pass them along to someone who needs to know such
  • [10:33:00] <koen> revision of the kernel to be exact :)
  • [10:33:06] <zodttd> aha :)
  • [10:33:29] <koen> I suspect if you install debian you also can't rotate the FB :)
  • [10:34:45] <koen> When the ehci stuff is sorted out I can finally try out my USB dvb stick on the beagle
  • [10:35:02] <zodttd> Yup, though the EVM has a 480x640 framebuffer screaming to be used as 640x480 ;P
  • [10:35:57] <zodttd> Though what I will eventually be using will be a landscape oriented 800x480 screen with the framebuffer to match
  • [10:36:26] <zodttd> So a lot of my distro concerns, as you imply, will be nullified when things mature with the hardware I work with
  • [10:37:42] <koen> when doing an emu you will probably first hit things like kernel problems (lack of HW rotate)
  • [10:38:55] <zodttd> Yeah
  • [10:39:25] <koen> ldesnogu: so if I compile fftw with -mfpu=neon -mfast-math -ftree-vectorize -mcpu=cortex-a8 I should get a magic performance increase?
  • [10:39:27] <zodttd> In the meantime I either dont rotate and scale so it fits portrait or just software rotate and scale
  • [10:39:36] <koen> ldesnogu: That's how I read teh ARM propagande :)
  • [10:39:36] <zodttd> koen: I was wondering the same
  • [10:39:59] <zodttd> beat me to the question heh
  • [10:40:19] <koen> from http://www.arm.com/products/CPUs/NEON.html :
  • [10:40:21] <ldesnogu> make that -ffast-math and then perhaps :)
  • [10:40:40] <koen> " Developed with vectorizing compiler technology in mind, NEON technology provides an acceleration solution that can be exploited through high level code without the need for intrinsic functions or hand written assembly."
  • [10:40:53] <ldesnogu> mouhahaha
  • [10:40:57] <ldesnogu> oups sorry :)
  • [10:41:38] <ldesnogu> I won't make an official statement on that claim, but I would not trust it
  • [10:41:44] <koen> Since I'm used to ARMs reality distortion field that means: "If you use our own $$$$$$$$ compiler everyting will work. Don't use gcc"
  • [10:42:15] * koen ponders about llvm support for NEON
  • [10:42:29] <ldesnogu> koen: times are changing, and some public benchmarks have shown that except for dhrystone gcc and armcc are the same
  • [10:42:35] <zodttd> LLVM for ARM ughhh!
  • [10:42:38] <zodttd> Just say no
  • [10:42:51] <koen> llvm rocks
  • [10:42:55] <zodttd> For ARM though?
  • [10:42:58] <ldesnogu> LLVM is C++ so stinks by construction
  • [10:43:15] <koen> I have seen benchmarks that improve performance by 5% over gcc on arm
  • [10:43:31] <koen> armv5te, that is
  • [10:43:41] <ldesnogu> you mean armcc produces code that is 5% faster than gcc?
  • [10:44:00] <zodttd> I have used it on iPhone and is was scary. sauriks toolchain removed LLVM and got twice the performance out of binaries
  • [10:44:05] <koen> no, llvm compiles a gtk+ that is 5% faster than gtk+ compiled with gcc
  • [10:44:12] <ldesnogu> oh OK :)
  • [10:44:21] <koen> gcc-csl even
  • [10:44:36] <ldesnogu> and how many were faster with gcc? ;)
  • [10:44:41] <zodttd> Plus there were a lot of LLVM bugs in the revision that was required for iPhone
  • [10:44:52] <zodttd> Some affected my code
  • [10:45:11] <koen> this was with llvm from svn ( at the time )
  • [10:45:21] <zodttd> I heard LLVM for ARM is not supported by their group
  • [10:45:36] <zodttd> It's expiremental or such
  • [10:45:41] <koen> yeah
  • [10:45:46] <koen> it wasn't written by apple :)
  • [10:45:54] <koen> it was written by indt brazil :)
  • [10:46:12] <zodttd> heh
  • [10:46:23] <ldesnogu> there were some rumors that the LLVM team was tiny
  • [10:46:40] <zodttd> Well I was actually comparing to the iphone-dev toolchain 0.30, which was scary
  • [10:47:01] <koen> it depends how you use llvm
  • [10:47:19] <koen> the indt guys made use of its LTO and better codegen
  • [10:47:26] <koen> they didn't use the JIT or VM mode
  • [10:47:35] <koen> which is probably what the iphone stuff does
  • [10:47:40] <zodttd> aha
  • [10:48:45] <koen> the JIT/VM approach means you always have to access the 10MB runtime
  • [10:48:51] <zodttd> Should -mfloat-abi=softfp be added to the magical CFLAGS?
  • [10:49:00] <zodttd> I heard it was needed for NEON to work
  • [10:49:10] <koen> iirc that is default in the gcc .spec
  • [10:49:18] <zodttd> aha ok
  • [10:49:24] <koen> but it wouldn't hurt
  • [10:49:56] <ldesnogu> zodttd: yes, see https://support.codesourcery.com/GNUToolchain/kbentry29
  • [10:50:03] <zodttd> yeah thats where i heard
  • [10:50:04] * koen checks gcc -dumpspecs
  • [10:50:16] <zodttd> koen: Which toolchain are you using?
  • [10:50:17] <koen> ah right, that one isn't in the specs
  • [10:50:24] <zodttd> aha
  • [10:50:26] <koen> atm gcc 4.3.0
  • [10:50:35] <zodttd> CodeSourcery?
  • [10:50:38] <koen> but I might try csl 2008q1 to test fftw
  • [10:50:42] <koen> no, no csl
  • [10:50:43] <zodttd> oh
  • [10:51:06] <ldesnogu> 2008q1 is based on gcc 4.2.3
  • [10:51:21] <zodttd> koen: Does your toolchain support NEON?
  • [10:51:25] <zodttd> oh
  • [10:51:26] <ldesnogu> and I personally would be extremely careful with a gcc release ending in 0 :)
  • [10:51:51] <zodttd> ldesnogu: Newer is better ;P
  • [10:51:53] <koen> gcc 4.3.0 is a pain because the gcc dudes changed its buildsystem, various include locations and more
  • [10:52:01] <zodttd> oww
  • [10:52:19] <ldesnogu> zodttd: I love stability :)
  • [10:52:32] <zodttd> ldesnogu: I wonder why I was told to use 2007q3
  • [10:52:38] <ldesnogu> can't say
  • [10:52:42] <zodttd> hmm
  • [10:52:46] <koen> zodttd: because 2008q1 wasn;t released at that time?
  • [10:52:48] <ldesnogu> 2008q1 had not been out for long
  • [10:52:49] <zodttd> If 2008q1 works I will use it
  • [10:52:51] <zodttd> ah
  • [10:52:51] <ldesnogu> hehe
  • [10:53:12] <zodttd> If it was released in the past few weeks thats probably why
  • [10:53:13] <ldesnogu> 2008q1 has cortex-a9 support, isn't that nice? :D
  • [10:53:28] <koen> send me a devboard with an a9 and I'll test it :)
  • [10:53:28] <zodttd> Sounds like Im using ancient tech ;P
  • [10:53:33] <zodttd> lol
  • [10:53:43] <ldesnogu> koen: lemme get an a9 dev board first ;)
  • [10:54:37] <ldesnogu> usually when ARM publicizes a new core, it takes one to two years to get silicon
  • [10:56:23] <ldesnogu> that's funny a few months back a wikipedia page was claiming omap4 will be based on cortex-A9
  • [10:56:40] <ldesnogu> that page has been edited it seems
  • [10:57:04] <koen> what are the big differences between a8 and a9?
  • [10:57:07] <koen> new instructions?
  • [10:57:25] <ldesnogu> you guess I can't say too much, so here we go for public info
  • [10:57:31] <ldesnogu> out of order
  • [10:57:36] <ldesnogu> pipelined VFP
  • [10:57:46] <ldesnogu> instruction set is basically the same
  • [10:58:06] <ldesnogu> optional VFP and NEON
  • [10:58:20] <ldesnogu> HW support for SMP up to 4 cores
  • [10:58:33] <ldesnogu> external L2 cache
  • [10:58:46] <koen> so a9 is more like a "sister" than a "daughter"
  • [10:59:01] <ldesnogu> hum
  • [10:59:05] <ldesnogu> no :)
  • [10:59:08] <koen> :)
  • [10:59:16] <ldesnogu> it's neither
  • [10:59:34] <koen> I read it as "same ISA, better silicon"
  • [10:59:58] <ldesnogu> better micro architecture, yes
  • [11:05:26] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [11:07:13] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [11:07:36] <ldesnogu> koen: are you sure ??? CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE affects page sizes at ARM MMU level?
  • [11:09:05] <zodttd> Whats the difference between ARM GNU/Linux and ARM EABI? I noticed koen mentioned EABI just earlier
  • [11:09:17] <zodttd> Im about to try out the 2008q1
  • [11:09:21] <ldesnogu> ARM EABI is for bare metal
  • [11:09:32] <ldesnogu> pick the one that mentions Linux
  • [11:09:43] <ldesnogu> it uses EABI anyway
  • [11:09:43] <zodttd> ah ok
  • [11:09:48] <zodttd> Ohhh ok
  • [11:09:54] <zodttd> Thats what i wasnt sure of
  • [11:10:09] <koen> linuxgnueabi in the host triplet
  • [11:10:18] * ldesnogu wonders how to check out a git...
  • [11:10:21] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) Quit (Client Quit)
  • [11:10:25] <zodttd> Use git
  • [11:10:33] <zodttd> git clone
  • [11:10:38] <koen> ldesnogu: it magically appears on your drive ;)
  • [11:10:44] <ldesnogu> :-/
  • [11:11:06] <ldesnogu> so that would git clone linux-omap-address
  • [11:11:14] <ldesnogu> and what is ???linux-omap-address?
  • [11:11:53] * ali_as (n=as@ambix.plus.com) has joined #beagle
  • [11:12:10] <ldesnogu> git clone git://source.mvista.com/git/linux-omap-2.6.git ?
  • [11:12:46] <zodttd> looks right, though im new to git as well
  • [11:13:00] <zodttd> :P
  • [11:13:35] <ldesnogu> git looks strange to me; I have used cvs, svn, clearcase, and git is again some other beast
  • [11:16:31] <koen> ldesnogu: http://www.muru.com/linux/omap/README_OMAP_GIT
  • [11:16:43] <koen> ldesnogu: think of git like rcs
  • [11:16:52] <koen> ldesnogu: it's really low-level with a ton of wrappers
  • [11:18:49] <koen> and http://www.muru.com/linux/omap/README_OMAP_PATCHES if you want to send patches upstream :)
  • [11:20:31] <ldesnogu> thanks a lot for the links
  • [11:21:44] <ldesnogu> that gentoo page is really hilarious
  • [11:29:08] <ldesnogu> nice one: http://lists.arm.linux.org.uk/lurker/message/20080510.153928.efee72fe.en.html
  • [11:29:27] <ldesnogu> I hope there's no similar overlook in v7 kernel stuff :)
  • [11:30:00] * ali_as_ (n=as@ambix.plus.com) Quit (Read error: 110 (Connection timed out))
  • [11:45:00] <koen> lennert rocks
  • [11:45:20] <ldesnogu> koen: CONFIG_FB is not set in the beagle defconfig, is that expected? I mean some of your patches were not pushed?
  • [11:45:29] <ldesnogu> yeah, Lennert is a smart guy :)
  • [11:45:42] <koen> I never pushed defconfig patches
  • [11:45:48] <ldesnogu> oh OK
  • [11:47:18] <koen> ldesnogu: http://amethyst.openembedded.net/~koen/beagleboard/OE-kernel-stuff/
  • [11:47:28] <koen> all patches I use on top of git and the defconfig
  • [11:47:41] <koen> the RTC one was accepted, but tony forgot to push it
  • [11:47:59] <ldesnogu> the patch window is closed?
  • [11:49:31] <koen> linux-omap has no patch window
  • [11:49:52] <koen> tony pushes some fixes to RMK every merge window, not all new stuff
  • [11:51:50] <koen> ldesnogu: http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=summary and scroll down to "heads"
  • [11:52:04] <koen> ldesnogu: RMK pulls the "omap fixes" branch
  • [11:52:11] <ldesnogu> regarding the FB DMA config flag you talked about, it seems to do what I wanted, but I need to check the lower level parts of the kernel is using 1 MB pages
  • [11:52:51] <koen> the help text says "needs to be 2MB aligned"
  • [11:52:55] <koen> (it defaults to 2MB)
  • [11:53:05] <ldesnogu> pull means he takes things there and add them to his git?
  • [11:53:17] <koen> but help texts have been wrong before
  • [11:53:19] <ldesnogu> the 2MB alignment doesn't mean much :)
  • [11:53:34] <ldesnogu> as far as MMU alignment are concerned I mean
  • [11:53:43] <koen> ldesnogu: 'pull' means that RMK imports the changes tony puts in the 'omap-fixes' branch
  • [11:53:59] <ldesnogu> the MMU has support for 4 KB, 64 KB, 1 MB and 16 MB pages
  • [11:54:03] <koen> (a 'head' is kind of like a branch in git speak)
  • [11:54:27] <ldesnogu> koen: I am lost, I will try to find some git for dummies page :)
  • [11:55:42] <koen> ldesnogu: if you follow the muru.com instructions you will get the linux-omap tree with all the latest stuff that was accepted on the linux-omap mailinglist
  • [11:56:24] <koen> ldesnogu: mainline (linus) doesn't have much omap stuff, but tony keeps the stuff that is there working (the omap-fixes)
  • [11:57:13] <ldesnogu> here is what I understood: initial "checkout" -> git clone git://source.mvista.com/git/linux-omap-2.6.git
  • [11:57:15] <koen> every now and then tony pushes a bunch of new stuff to RMK (e.g. beagle and evm support)
  • [11:57:20] <ldesnogu> then to update: git pull
  • [11:57:26] <koen> right
  • [11:57:37] <koen> that works over multiple branches under the hood
  • [11:58:16] <ldesnogu> I think once I will have a mapping between svn terminology and git, I will be mostly ready to be a user (as opposed to ready to be a dev :))
  • [11:58:50] <ldesnogu> pull = update; push = commit
  • [11:59:05] <koen> ldesnogu: to give an example between linux-omap 'master' and linux-omap 'omap-fixes': vfp3 support has been in 'master' for months, but not in 'omap-fixes'
  • [11:59:21] <koen> ldesnogu: no, push = send commits to server
  • [11:59:41] <ldesnogu> how does that differ from commit?
  • [11:59:56] <koen> commit commits to your local repository
  • [12:00:03] <ldesnogu> (if you're tired babysitting me, don't answer, I can google ;))
  • [12:00:07] <ldesnogu> oh OK
  • [12:00:19] <koen> git only communicates with the server during 'push' and 'pull'
  • [12:00:39] <koen> that's why diff is so fast in comparison with cvs can svn
  • [12:01:07] <koen> (svn cheats and keeps the previous revision on disk to have fast diff, but hits the server if you diff over multiple revisions)
  • [12:01:58] <koen> (and which is why an svn checkout is approx twice the size of the tarball release)
  • [12:02:20] <ldesnogu> I know that about svn :)
  • [12:05:22] <koen> and with git you almost never commit to the main branch
  • [12:06:05] <koen> you create a new one "git branch ldesnogu-foo", commit and do 'git-format-patch -1' and mail the patch
  • [12:06:17] <ldesnogu> you commit to your local branch, and then send git patches to the appropriate mailing-list for review?
  • [12:06:21] <koen> and then switch back to the main branch with 'git checkout master'
  • [12:06:24] <koen> yes
  • [12:06:27] <ldesnogu> ok got it right :)
  • [12:07:04] <koen> if you box has a working email setup 'git-send-mail' is the preffered option
  • [12:07:52] <ldesnogu> I certainly am not at this point, but I will have to find a solution, since I only use gmail web based interface
  • [12:08:00] <koen> saves you a bunch of "OMG whitespace damage !!!!11!!11!!oneoneone!!" mails
  • [12:08:05] <ldesnogu> hehe
  • [12:08:22] <koen> I don't have such a box, so I have to hope OSX' Mail.app doesn't damage it too much
  • [12:09:22] <ldesnogu> I guess I can setup some mail on my Fedora box and use gmail as my SMTP
  • [12:10:42] <ldesnogu> gmail indeed has an SMTP server, cool
  • [12:11:14] <koen> an open-relay smtp server even
  • [12:11:38] <koen> http://it.slashdot.org/it/08/05/11/014234.shtml
  • [12:12:10] <ldesnogu> that's not very good...
  • [12:12:50] <ldesnogu> well I don't intend on spamming
  • [12:13:39] <ldesnogu> I had to shutdown some facility on a mailing list I administer two days ago: I had received 2,000 spams during the night
  • [12:14:11] <ldesnogu> I wonder if it's related to that gmail flaw
  • [12:32:33] <koen> nice
  • [12:32:46] <koen> the beagle is fast enough to decode the matrixbench avi in Xfbdev
  • [12:34:52] <ldesnogu> at what resolution?
  • [12:35:16] <koen> windowed with a desktop of 1024x786
  • [12:35:41] <ldesnogu> what CPU usage did you get?
  • [12:35:59] <koen> matrixbench_normdivx_vbrmp3.avi from http://samples.mplayerhq.hu/benchmark/testsuite1/
  • [12:36:02] * koen checks top
  • [12:36:38] <koen> 60% cpu
  • [12:36:58] <ldesnogu> that's using mplayer with no armv6?
  • [12:37:12] <koen> armv6 vfp code from siarhei
  • [12:37:17] <ldesnogu> ok :)
  • [12:37:19] <koen> no neon or fancy stuff
  • [12:37:46] <ldesnogu> NEON could double the speed of some functions and perhaps even more since the VFP is not pipelined
  • [12:39:43] <koen> I should send a beagle to lrg
  • [12:39:55] <koen> he would love the pops and clicks of the .22 audio driver
  • [12:40:01] <ldesnogu> ??? lrg ?
  • [12:40:15] <koen> Liam Girdwood, the Alsa SoC guy from Wolfson Micro
  • [12:40:49] <koen> switching on/off the internal amps gives you a 'pop' in the sub 200Hz range
  • [12:41:06] <koen> with a decent subwoofer it will blow your socks off
  • [12:41:44] <koen> play audio 'pop' 'pop' 'POP' <audio> 'pop' 'POP'
  • [12:42:38] <koen> your ipod probably does it as well
  • [12:43:21] <koen> newer codecs can do pop/click reduction in hardware, older need software workarounds
  • [12:45:13] <ldesnogu> omg Siarhei is using the deprecated vector VFP instructions
  • [12:46:00] <koen> he only have a omap2420 to work on
  • [12:46:07] <koen> with an ancient gcc3 csl toolchain
  • [12:46:14] <koen> s/have/has/
  • [12:46:35] <ldesnogu> I am not sure how that works on a Cortex-A8!
  • [12:47:16] <ldesnogu> Cortex-A8 still has vector stuff :)
  • [12:50:44] <koen> I compiled his mplayer with -march=armv7a -mcpu=cortex-a8, but without -mfpu=neon
  • [12:51:16] <ldesnogu> since he is using assembly code for critical code, I am not sure the neon flag would help
  • [12:51:30] <koen> I figured as much
  • [12:52:00] <koen> while mplayer makes a nice demo, other stuff will make a bigger diference
  • [12:52:17] <koen> like using the overlays to put the picture on screen
  • [12:52:32] <koen> and using the DSP to do various decoding
  • [12:52:58] <ldesnogu> no doubt the DSP could help a lot
  • [12:53:04] <koen> right now I have a armv6 optimized mplayer using the arm cpu to output to a dumb framebuffer
  • [12:53:24] <ldesnogu> does OMAP3530 have hardware overlay? And if so does that require imgtec libs?
  • [12:53:33] <koen> if I where an omap designer I'd breadown and cry ;)
  • [12:53:41] <koen> break*
  • [12:53:41] <ldesnogu> koen: that indeed looks like a worst case scenario :)
  • [12:54:37] <koen> it's the current scenario :(
  • [12:55:08] <koen> I would love to see a gstreamer based player using the openmax codecs + accelerated X
  • [12:55:27] <koen> (or unaccelerated X + libXsp)
  • [12:56:08] <koen> (libXsp == "don't repaint region <x,y><x2,y2>, I'm blitting using DSP there")
  • [12:56:21] <ldesnogu> what openmax codecs are you talking about?
  • [12:56:52] <ldesnogu> the ARM openmax library only has low level stuff IIRC; one would have to implement the real codec using OpenMAX DL
  • [12:59:51] <koen> iirc they opensourced gstreamer plugins using those as well
  • [13:00:07] <ldesnogu> you mean TI?
  • [13:00:12] <koen> http://freedesktop.org/wiki/GstOpenMAX
  • [13:01:13] <ldesnogu> well ARM provides an OpenMAX DL NEON optimised library
  • [13:01:28] <ldesnogu> I need to check if the EULA does not conflict with GPL
  • [13:02:03] <ldesnogu> I will have to get in touch with ARM lawyers, might be fun :)
  • [13:02:38] <koen> "GstOpenMAX is a collaboration among Fluendo, Nokia, STMicroelectronics, TI and the open-source community, initiated by Nokia with the goal to develop a GStreamer plugin to run OpenMAX-IL components in GNOME and GStreamer applications. The new project aims to merge efforts from Bellagio project and GOmx project into one solid OMAX-IL plugin for GStreamer."
  • [13:03:19] <koen> funny how arm is all "use NEON with OpenMax!!!!" and TI is all "use OpenMax on our c64x DSP!!!!"
  • [13:03:28] <ldesnogu> :)
  • [13:03:45] <ldesnogu> both of the approaches have their own set of advantages
  • [13:03:50] <koen> right
  • [13:04:09] <koen> on the nokia n8xx using the DSP means the arm core gets clocked down
  • [13:04:11] <ldesnogu> I don't know how power hungry the c64x+ is compared to the NEON unit
  • [13:04:39] <koen> so it often is faster to not use the DSP and utilize the sparce 150Mhz on the cpu
  • [13:04:52] <koen> s/sparce/spare/
  • [13:04:58] * koen can't type today
  • [13:05:17] <ldesnogu> that stinks!
  • [13:05:38] <ldesnogu> it looks like it's not the same on OMAP3530
  • [13:06:17] <koen> I also think it depends on what framework you use (dspbridge, dsplink, dspfs, whatever)
  • [13:06:57] <ldesnogu> I would hope that once setup this does not change performance a lot (less than 5%)
  • [13:07:50] <ldesnogu> naively I would expect that you upload some code on the DSP, and then you "only" have to stream data
  • [13:08:00] <koen> I kinda suspect the nokia engineers screwed up
  • [13:08:16] <ldesnogu> gstreamer is Nokia originally right?
  • [13:08:52] <koen> it's complex
  • [13:09:04] <koen> gstreamer was started as a regular opensource project
  • [13:09:41] <koen> then ridgerun inc sponsored it to get it working on arm+dsp cores (omap, but I'm not sure), then ridgerun went bust and gstreamer dudes concentrated on desktop usage
  • [13:10:04] <koen> and 2 years ago nokia picked it up for their tablets, once again tweaking it for omap
  • [13:11:02] <koen> it's amazing how far TI has come with opening up docs, code and specs in those 2 years
  • [13:11:16] <ldesnogu> hum usually a complex story like that is not a good sign for code :)
  • [13:11:48] <koen> ever looked at opensource multimedia frameworks?
  • [13:11:51] <ldesnogu> koen: I am all the more impressed due to working there some years ago :)
  • [13:12:06] <ldesnogu> which framework?
  • [13:12:13] <ldesnogu> there are dozens, no?
  • [13:12:17] <koen> ffmpeg, xine, vlc, gstreamer
  • [13:12:28] <ldesnogu> the most used one being Windows DLL wrapping :D
  • [13:12:36] <koen> :)
  • [13:12:56] <koen> our mplayer export in OE got asked to enable DLL loading on the strongarm version
  • [13:13:01] <ldesnogu> isn't ffmpeg the most advanced one?
  • [13:13:03] <koen> expert*
  • [13:13:07] <ldesnogu> lol
  • [13:13:17] <koen> ffmpeg developers don't know what "API" or "ABI" means
  • [13:13:24] <ldesnogu> that might be fun to do that using qemu :p
  • [13:13:51] <koen> it's the fastest one for most codecs, but you are forced to fork it, since upstream breaks api hourly
  • [13:13:54] <ldesnogu> well the project creator certainly knows the difference
  • [13:14:25] <ldesnogu> but I think he's not worked on ffmpeg for years
  • [13:14:53] <koen> gstreamer is the sanest one, due to it's "pipeline" design, but has big overhead on "embedded" systems
  • [13:15:06] <koen> or rather "had"
  • [13:15:27] <koen> and there's a gst-plugin-ffmpeg to use ffmpeg inside gstreamer
  • [13:15:37] <ldesnogu> "had" because embedded systems are now powerful, or because they sanitized it?
  • [13:15:54] <koen> sanitized it
  • [13:16:01] <ldesnogu> ok
  • [13:16:16] <koen> there was a discussion about pulseaudio a while back
  • [13:16:37] <koen> the project lead said 'no soundcard does hw mixing anymore, and your CPU is powerfull enough'
  • [13:17:01] <koen> the 'embedded' people said "all our cards to hw mixing and our CPUs aren't powerfull enough'
  • [13:17:41] <ldesnogu> who won in the end?
  • [13:18:15] <koen> I think then embedded people got their point through, but I'm not sure on the actual code status
  • [13:18:35] <koen> on the omap you would use the DSP to mix pcm streams anyway :)
  • [13:18:53] <koen> but it shows the disconnect between 'desktop' and 'embedded'
  • [13:18:53] <ldesnogu> I thought all audio chips are doing HW mixing even those on newer PC motherboards
  • [13:19:12] <koen> no, newer chips bump it to the CPU
  • [13:19:22] <koen> saves $0.20 on the silicon or something like that
  • [13:19:24] <ldesnogu> even discrete ones?
  • [13:19:43] <ldesnogu> I bet Xfi and other proprietary have very powerful DSP that do all the work
  • [13:20:01] <koen> yes, but those don't end up in cheap PCs :)
  • [13:20:06] <ldesnogu> :)
  • [13:20:22] <koen> but most people have a dual core 2GHz cpu nowadays
  • [13:20:34] <koen> so mixing 10 pcm streams is virtually free
  • [13:20:48] * ldesnogu looks at his Athlon 64 3500+ and cries
  • [13:23:50] * koen just discovered jaaa (http://www.kokkinizita.net/linuxaudio/)
  • [13:28:21] <ldesnogu> #error ARM Coherent DMA allocator does not (yet) support huge TLB
  • [13:28:23] <ldesnogu> nice :(
  • [13:56:11] <koen> so disable hugetlb :)
  • [13:58:06] <ldesnogu> I would like to give it a try on SPEC2k benchmarks ;)
  • [13:58:22] <ldesnogu> TLB can have a really big impact on performance
  • [13:59:31] <koen> running those benchmarks could be a nice QA tool
  • [13:59:59] <ldesnogu> except you can't run all of them on Beagle because they require 256 MB of RAM
  • [14:00:06] <ldesnogu> but yes I agree with you :)
  • [14:00:29] <koen> why do they require so much ram?
  • [14:00:49] <ldesnogu> strange question :)
  • [14:01:06] <ldesnogu> well it depends on what the benchmark does and its data set
  • [14:01:21] <ldesnogu> spec 2006 requires 1 GB for instance
  • [14:01:40] <ldesnogu> it more or less reflects typical RAM sizes of moderately sized workstations
  • [14:01:59] <ldesnogu> in 2000 they decided 256 MB was the sweet spot I guess
  • [14:02:44] <ldesnogu> if you want gory details: http://www.spec.org/cpu2000/analysis/memory/
  • [14:07:23] <koen> maybe spec95 would run :)
  • [14:07:33] <koen> but that's 13 years old now
  • [14:08:03] <koen> maybe TI will make a beagle with a PoP with 1GB of RAM
  • [14:14:43] <ldesnogu> spec95 will certainly run, but I am not sure I have access to it
  • [14:14:46] * koen grumbles at benchfft refusing to (cross)compile
  • [14:14:54] <ldesnogu> really?
  • [14:15:24] <koen> it needs to run generated tools (my athlon can't run arm code) and native compilation chokes somewhere in std::foo
  • [14:15:26] <ldesnogu> I am surprised given the work they have done recently for the PS3; I had perhaps wrongly assumed they were using cross-compilation
  • [14:15:58] <koen> most people think cross-compilation is hard
  • [14:16:02] <ldesnogu> did you try compile natively for your athlon?
  • [14:16:29] <koen> no, on the beagle :)
  • [14:17:09] <koen> having a 1GB sd card rocks
  • [14:17:11] <ldesnogu> perhaps you could try your athlon first; that could clear the possibility there's a g++ 4 problem :)
  • [14:17:28] <ldesnogu> (assuming your athlon runs gcc 4)
  • [14:17:55] <koen> I suspect there's a .la problem on the beagle
  • [14:18:07] <koen> there's something slightly wrong with how OE uses libtool
  • [14:18:15] * ldesnogu hates libtool
  • [14:18:30] <koen> but our libtool dude is working with upstream now and at least 2 of his patches made 2.2.4
  • [14:18:41] <koen> but 2.2.4 breaks a lot of existing applications
  • [14:18:59] <koen> e.g. ECHO isn't defined anymore
  • [14:19:06] <koen> or LT_ECHO, I forget
  • [14:28:41] * BThompson (n=BThompso@cpe-76-185-66-252.tx.res.rr.com) has joined #beagle
  • [14:55:54] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [14:56:55] <sakoman> koen: any trick to building minimo with latest .dev? My build dies with "cat: ./config/build_number: No such file or directory"
  • [15:05:02] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) has joined #beagle
  • [15:18:12] <koen> no idea
  • [15:18:22] <koen> I try to boycot mozilla stuff as much as possible
  • [15:18:31] * koen spent too much time getting it to build/work
  • [15:20:01] <koen> example: the makefile checks out cvs by itself instead using the one you provide
  • [15:22:07] <koen> sakoman: did you already see http://linux.omap.com/pub/kernel/3430sdp/patches-applicable-over-linux-omap-2.6.git/audio_34xx_support_20071220.patch ?
  • [15:33:33] <sakoman> koen: no haven't looked at that one! Looks interesting though
  • [15:35:44] <koen> (doesn't apply, but it largely is a new file and a bunch of void->int stuff)
  • [15:36:22] <sakoman> I wonder what vintage git it used to apply to
  • [15:36:47] <koen> the file was uploaded a month ago
  • [15:36:55] <sakoman> If it is the same as the 2.6.22 stuff I looked at earlier it had a lot of other issues too
  • [15:37:06] <koen> and the (c) says: * 2007/12/17 Misael Lopez Cruz - Added support for 3430 platform
  • [15:37:13] <koen> so it's not that old
  • [15:37:43] <koen> does anyone know of an interactive patch editor that isn't emacs?
  • [15:38:07] <sakoman> I'll try to take a look later this evening
  • [15:38:15] <koen> e.g. like meld, but takes a dir and a patch as argument instead of 2 dirs?
  • [15:40:55] <sakoman> koen: I fear that this code might have the same mcbsp issue that I saw with the 2.6.22 stuff (i.e. git version differs from TI internal version)
  • [15:41:18] <sakoman> But I'll look at it later, got to run now
  • [15:42:11] <koen> drat
  • [15:42:17] <koen> I forgot about the mcbsp feud
  • [16:00:24] <ldesnogu> I wonder why every API in the world tries to redefine sized integer types with different names :(
  • [16:08:42] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [16:15:56] * koen runs benchfft
  • [16:16:09] <koen> it indeed was a broken .la file for libstc++
  • [16:16:51] <koen> ldesnogu: because they can
  • [16:20:06] <ldesnogu> they should be shot for that
  • [16:20:47] <ldesnogu> and most of them don't suffix their types with _t, I hate all of them :p
  • [16:20:58] <ldesnogu> so how is benchfft going?
  • [16:21:10] <ldesnogu> did you use NEON and vectorizing?
  • [16:21:42] <koen> no, only -mfpu=vfp
  • [16:21:50] <koen> I only have stock gcc 4.2.2 as native compiler
  • [16:22:05] <koen> when I get it to crosscompile I can try 2008q1 with neon
  • [16:22:21] <ldesnogu> or recompile 2008q1 :)
  • [16:22:41] * koen notes that gcc 4.3.1 was due 6 days ago
  • [16:23:08] <ldesnogu> they still have P1 bugs IIRC
  • [16:23:51] <ldesnogu> http://gcc.gnu.org/ml/gcc/2008-05/msg00059.html
  • [16:25:12] <koen> just reading that
  • [16:25:28] <koen> didn't realy the april archive only covered april
  • [16:25:33] * koen needs some coffee
  • [16:26:01] <ldesnogu> :)
  • [16:32:52] * koen downloads 2008q1 sources
  • [16:34:20] <ldesnogu> I hope you did not forget to select the GNU/Linux one, I already did that mistake :)
  • [16:39:26] * like2wise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [16:41:17] * jkridner|wor1 is now known as jkridner|work
  • [17:12:38] <koen> work on sunday?
  • [17:25:09] * koen does a sed -i s:2006:2008:g on the OE csl recipes
  • [17:40:55] <ldesnogu> you were using 2006q1?
  • [17:41:36] <koen> no, we have build descriptions for 2006q1 in OE :)
  • [17:41:49] <ldesnogu> oh very nice!
  • [17:42:15] <koen> it's currently compling gcc 2008q1 as crosscompiler
  • [17:42:20] <ldesnogu> I remember the time I spent cleaning the .sh script provided by CSL to understand how they build their toolchain
  • [17:42:29] <ldesnogu> if only I had known...
  • [17:45:16] <ldesnogu> FULL_OPTIMIZATION_armv7a = "-fexpensive-optimizations -ftree-vectorize -fomit-frame-pointer -O2"
  • [17:45:31] <ldesnogu> is that tree-vectorize really a boost?
  • [17:45:49] <ldesnogu> it's in glibc.inc
  • [18:19:15] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) has joined #beagle
  • [18:29:15] <koen> no idea
  • [18:29:24] <koen> -mfpu=neon ICEs gcc 4.3.0
  • [18:29:32] <koen> as does -frename-registers
  • [18:35:50] * bazbell (n=a0192809@nat/ti/x-efb96ba9c0c46eb2) has joined #beagle
  • [18:35:58] <koen> ldesnogu: I went gentoo on the cflags in glibc.inc :)
  • [18:37:47] * JoeBorn_ (n=jborn@adsl-75-2-242-90.dsl.chcgil.sbcglobal.net) has joined #beagle
  • [19:02:53] * JoeBorn_ is now known as JoeBorn
  • [20:00:30] <Crofton> Guinness is good for you
  • [20:16:18] <koen> it indeed is
  • [20:16:34] <koen> Crofton: did you get my mails?
  • [20:23:23] <Crofton> yeah
  • [20:23:41] <Crofton> just finished a guineess too
  • [20:24:32] <koen> :)
  • [20:25:10] <koen> Crofton: I'm adding gcc 2008q1 to OE
  • [20:25:31] <jkridner> koen: for x86 or ARM?
  • [20:25:53] <Crofton> good, that might let us run neon then
  • [20:26:11] <Crofton> are you going to get anywhere bemchmarking fftw?
  • [20:26:12] <jkridner> koen: building it or using it?
  • [20:26:19] <Crofton> I've skimmed to log from tofay
  • [20:26:19] <koen> cross-compiler, so both x86 and arm :)
  • [20:26:32] <koen> Crofton: .22 crashed while running the benchmarks
  • [20:27:08] <Crofton> urg
  • [20:28:15] <koen> lets see if ext3 can save the logs
  • [21:17:50] <ldesnogu> it crashed while only the benchmarks were running?
  • [21:17:57] <ldesnogu> or also x11 and other stuff?
  • [21:34:30] <koen> only the benchmarks
  • [21:34:43] <koen> high cpuload == crash on beagle, regardless of kernel
  • [21:34:51] <koen> I suspect the TWL freaks out
  • [21:34:55] <ldesnogu> oh :(
  • [21:35:38] <ldesnogu> it's a kernel crash or the beast just freezes?
  • [21:36:54] <koen> it freezes, but sysrq works
  • [21:37:46] <ldesnogu> so interrupts are still being serviced and parts of the IO?
  • [21:38:47] <koen> cursors blink, but no way to do stuff over serial or network or console
  • [21:39:04] <koen> only sending sysrq over serial seems to have any effect
  • [21:39:11] <ldesnogu> how do you do a sysrq the? one of the buttons on the board?
  • [21:39:13] <ldesnogu> oh ok
  • [21:39:39] <koen> ctrl-a-a-f in minicom inside screen
  • [21:42:12] <koen> is tomorrow a holiday in the US?
  • [21:43:16] <jkridner> not that I know. Two weeks from Monday is. (Memorial Day)
  • [21:43:20] <ldesnogu> http://london.usembassy.gov/ukpubhol.html
  • [21:44:16] <koen> ah, so pentecost is a .nl holiday
  • [21:44:28] <ldesnogu> french too
  • [21:45:06] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [21:45:21] * NishanthM (n=Nishanth@cpe-24-175-68-203.tx.res.rr.com) has joined #beagle
  • [21:45:44] <koen> so I can move my laptop to the balcony tomorrow and be productive on a holiday
  • [21:45:57] <koen> since the uni is closed
  • [21:47:28] <Crofton> some guy here is working on hi spresentation for tomorrow
  • [21:47:31] <Crofton> and we are watching Hero
  • [21:51:24] <koen> people actually prepare for presentations?
  • [21:58:29] <Crofton> yeah
  • [22:06:15] * Crofton (n=balister@86-42-199-64.b-ras1.cld.dublin.eircom.net) Quit ("Leaving")
  • [22:09:39] <ldesnogu> gn all
  • [22:09:42] * ldesnogu (n=ldesnogu@ven06-2-82-247-86-183.fbx.proxad.net) has left #beagle
  • [22:18:07] * Crofton (n=balister@86-42-199-64.b-ras1.cld.dublin.eircom.net) has joined #beagle
  • [22:55:48] * Crofton (n=balister@86-42-199-64.b-ras1.cld.dublin.eircom.net) Quit (Remote closed the connection)
  • [23:05:52] * dannyBlue (n=chatzill@a213-22-212-28.cpe.netcabo.pt) has joined #beagle
  • [23:06:33] * dannyBlue (n=chatzill@a213-22-212-28.cpe.netcabo.pt) Quit (Client Quit)
  • [23:07:09] * dannyBlue (n=chatzill@a213-22-212-28.cpe.netcabo.pt) has joined #beagle
  • [23:07:56] * dannyBlue (n=chatzill@a213-22-212-28.cpe.netcabo.pt) Quit (Client Quit)