• [00:06:17] * mib_a9uvhg (i=5cec55b9@gateway/web/ajax/mibbit.com/x-492299be2f1aa045) Quit ("http://www.mibbit.com ajax IRC Client")
  • [00:18:18] * ldesnogu_ (n=ldesnogu@ven06-2-82-247-86-183.fbx.proxad.net) Quit ()
  • [00:20:35] * Guest66466 (n=lars@p5486C335.dip.t-dialin.net) has left #beagle
  • [00:22:14] * wtd_sicom (i=43a506e5@gateway/web/ajax/mibbit.com/x-a539dd203a8b6b1f) has joined #beagle
  • [00:24:28] <wtd_sicom> If you replace OMAP 35x on the Beagle board with a chip from distribution will it work or do you need special code for its on board rom?
  • [00:25:00] <mru> huh?
  • [00:26:39] <wtd_sicom> Same as producing your own product.
  • [00:27:16] <mru> there is only one omap3530 chip
  • [00:29:03] <wtd_sicom> Right now their is both protected and user rom inside 3530 has this rom been programed special for the Beagle project?
  • [00:29:25] <mru> the rom is not programmable
  • [00:29:32] <mru> it really is rom
  • [00:30:46] <wtd_sicom> It is programmable threw the jtag interface.
  • [00:30:56] <mru> I don't think so
  • [00:31:49] <wtd_sicom> Hope to have answer from TI on Monday
  • [00:32:37] <mru> how do you mean you'd write it through jtag?
  • [00:32:59] <mru> it's either mask rom or one-time-programmable
  • [00:33:10] <mru> whichever it is, you can't change it, ever
  • [00:34:44] * TAK2004 (n=Administ@dslb-088-074-046-097.pools.arcor-ip.net) Quit ("Verlassend")
  • [00:34:47] * wtd_sicom (i=43a506e5@gateway/web/ajax/mibbit.com/x-a539dd203a8b6b1f) Quit ("http://www.mibbit.com ajax IRC Client")
  • [00:59:38] * marc_collin (i=6014a5e5@gateway/web/ajax/mibbit.com/x-9aa3fec811184f45) has joined #beagle
  • [00:59:52] <marc_collin> hi
  • [01:00:26] <marc_collin> @adj_ i posted you an email... there is a couple of minut...
  • [01:00:33] <marc_collin> about you expansion board
  • [01:01:24] <marc_collin> have you buy it or created manually?
  • [01:02:32] * marc_collin (i=6014a5e5@gateway/web/ajax/mibbit.com/x-9aa3fec811184f45) Quit (Client Quit)
  • [01:28:07] * garren|work (n=chatzill@mail.dm.co.za) Quit (Read error: 110 (Connection timed out))
  • [01:38:13] * Leon_Nardella (n=leon@200-161-14-111.dsl.telesp.net.br) Quit (Remote closed the connection)
  • [01:40:45] * zedstar (n=john@fsf/member/zedstar) Quit (Remote closed the connection)
  • [01:43:47] * parapete (n=burgrlov@host81-154-145-29.range81-154.btcentralplus.com) Quit ("Leaving")
  • [01:48:27] * pku (n=pku@DSL01.83.171.160.244.ip-pool.NEFkom.net) Quit (Read error: 110 (Connection timed out))
  • [01:55:33] * fulgas is now known as FuL|OUT
  • [01:55:40] * Ryan45 (n=Ryan45@c-71-224-183-122.hsd1.pa.comcast.net) has joined #beagle
  • [01:56:02] * Ryan45 (n=Ryan45@c-71-224-183-122.hsd1.pa.comcast.net) has left #beagle
  • [02:34:18] * rsalveti (n=salveti@189.70.60.88) Quit (No route to host)
  • [02:34:29] * rsalveti (n=salveti@189.70.60.88) has joined #beagle
  • [02:47:10] * lcuk (i=lcuk@cpc1-oldh7-0-0-cust232.manc.cable.ntl.com) Quit ("Leaving")
  • [02:52:46] * matt_c (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) has joined #beagle
  • [02:57:02] * matt_c (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) Quit (Read error: 104 (Connection reset by peer))
  • [02:58:32] * matt_c (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) has joined #beagle
  • [03:27:57] * emeb_mac (n=ericb@ip72-223-90-212.ph.ph.cox.net) has joined #beagle
  • [03:28:22] * TheUni (n=cory@c-24-30-35-55.hsd1.ga.comcast.net) Quit (Read error: 113 (No route to host))
  • [03:29:04] * matt_c_ (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) has joined #beagle
  • [03:29:36] * emeb (n=ericb@ip72-223-90-212.ph.ph.cox.net) has joined #beagle
  • [03:30:09] * emeb_mac (n=ericb@ip72-223-90-212.ph.ph.cox.net) has left #beagle
  • [03:32:33] * matt_c_ (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) Quit (Remote closed the connection)
  • [03:34:27] * matt_c_ (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) has joined #beagle
  • [03:35:22] * matt_c__ (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) has joined #beagle
  • [03:43:25] * matt_c (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) Quit (Read error: 113 (No route to host))
  • [03:49:44] * matt_c_ (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) Quit (No route to host)
  • [04:25:47] * matt_c__ (n=mcroydon@pool-71-178-172-179.washdc.fios.verizon.net) Quit ()
  • [04:47:42] * guglhupf (i=4c660ca0@gateway/web/ajax/mibbit.com/x-272cbfb99719abb0) has joined #beagle
  • [04:48:27] * guglhupf (i=4c660ca0@gateway/web/ajax/mibbit.com/x-272cbfb99719abb0) Quit (Client Quit)
  • [04:50:07] * TehUni (n=cory@c-24-30-35-55.hsd1.ga.comcast.net) has joined #beagle
  • [05:37:26] * JoeyBorn (n=jborn@h-69-3-101-35.chcgilgm.dynamic.covad.net) has joined #beagle
  • [06:28:05] * emeb (n=ericb@ip72-223-90-212.ph.ph.cox.net) Quit (Read error: 110 (Connection timed out))
  • [06:34:07] * pku (n=pku@DSL01.83.171.164.229.ip-pool.NEFkom.net) has joined #beagle
  • [06:34:57] * pku (n=pku@DSL01.83.171.164.229.ip-pool.NEFkom.net) has left #beagle
  • [07:17:21] * JoeyBorn (n=jborn@h-69-3-101-35.chcgilgm.dynamic.covad.net) Quit (Read error: 60 (Operation timed out))
  • [08:40:49] * mib_phil (i=57ae0dd8@gateway/web/ajax/mibbit.com/x-4b84fbbd01f08d2c) has joined #beagle
  • [08:58:05] <raster> soon soon... i will have native compiling on my bb...
  • [09:16:32] <koen> raster: 'opkg install task-native-sdk'
  • [09:16:51] * koen already has native compiling on the beagle
  • [09:16:52] <raster> i dont have a repo set up
  • [09:16:59] <raster> too late now
  • [09:17:07] <raster> i have finally now got all the ipks installed i need
  • [09:17:12] <raster> and fixed fns so it mounts...
  • [09:17:25] <raster> i just wanted to edit on my desktop
  • [09:17:29] <raster> and cuild/run on bb
  • [09:17:32] <raster> build/run
  • [09:17:49] <raster> as this is specifically for doing the arm asm optimisations
  • [09:18:06] <raster> so i need to be on target to run/test - going via an oe corss-build hell will .. be unhappiness
  • [09:18:22] <koen> OE isn't really a development tool
  • [09:18:26] <raster> yup
  • [09:18:37] <raster> as i found out and bitched about at length when i first was wrestling with oe
  • [09:18:49] <raster> being a developer it was "wtf is this crap.. how am i meant to do any work?"
  • [09:18:55] <raster> i've come to terms with it now
  • [09:18:56] <raster> :)
  • [09:19:31] <raster> we.. get along
  • [09:19:57] <raster> first i want to see if pld's help
  • [09:20:01] <raster> on the 3530
  • [09:20:31] <raster> eh?
  • [09:21:39] <koen> raster: maybe this will help as well: http://git.mansr.com/?p=linux-omap;a=commit;h=3e1afa3f14f799e2757fdd60fe76de4ae4a66203
  • [09:21:52] <raster> nb
  • [09:22:23] <raster> 2.6.27+28 are totally screwed with usb host
  • [09:22:32] <raster> and usbnet devices
  • [09:22:41] <raster> one way or the other i'm back to 2.6.26 to get it working
  • [09:22:49] <raster> for now... i just need it working to do the asm
  • [09:23:04] <raster> hmm
  • [09:23:09] <raster> does that enable pld?
  • [09:23:47] <raster> ie
  • [09:23:49] <raster> #define pld(addr, off) \
  • [09:23:49] <raster> __asm__("pld [%[address], %[offset]]":: \
  • [09:23:49] <raster> [address] "r" (addr), [offset] "i" (off))
  • [09:23:49] <raster> #
  • [09:23:50] <koen> raster: http://groups.google.com/group/beagleboard/browse_thread/thread/12c7bd415fbc0993/c54dde7b9d55cf99?#c54dde7b9d55cf99
  • [09:24:10] <koen> raster: no, it enabled PLE, which is a fancier pld AIUI
  • [09:24:12] <koen> it's mru magic
  • [09:24:32] <raster> ooh
  • [09:24:33] <koen> "The Cortex A8 CPU has an L2 cache preload engine (PLE) [1], which can
  • [09:24:33] <koen> be used to preload large blocks of data into the L2 cache. Using
  • [09:24:34] <koen> this, I was able to push the copy throughput even higher"
  • [09:24:34] <raster> thats another thing
  • [09:25:36] <koen> yes
  • [09:25:47] <koen> and pld is armv5 and up right?
  • [09:26:16] <raster> yup
  • [09:26:32] <raster> already use it for evas's 16bit engine
  • [09:26:39] <raster> i was simply goign to throw it into the 32bit software engine
  • [09:26:55] <raster> thats a trivial first step
  • [09:27:53] <raster> and requires no specialty asm as its a "#ifdef - this is armv5. then put it in"
  • [09:28:02] <raster> tho.. the rest of the code doesnt do that
  • [09:28:13] <raster> its a runtime detect for available paths
  • [09:28:18] <raster> so technically u could compile for armv4
  • [09:28:28] <raster> and have optimisations kick in.. if on armv5,v6,v7 etc.
  • [09:28:41] <raster> but not sure if that really impacts u or not badly
  • [09:29:08] <raster> at this stage ho
  • [09:29:10] <koen> I suspect it compiler will choke if you pass -mcpu=arm920t
  • [09:29:15] <raster> i dont think i want to lock down the l2
  • [09:29:24] <raster> possibly
  • [09:29:30] <raster> on x86 its all doable
  • [09:29:51] <raster> crap
  • [09:29:51] <raster> ar is wrong
  • [09:30:00] <raster> busybox ar
  • [09:31:18] <raster> fixed
  • [09:32:20] * Sept (n=bakljg@c-98-240-226-129.hsd1.mn.comcast.net) Quit (Read error: 104 (Connection reset by peer))
  • [09:32:26] * Sept (n=bakljg@c-98-240-226-129.hsd1.mn.comcast.net) has joined #beagle
  • [09:33:34] * aleij (n=ad@183-239.76-83.cust.bluewin.ch) has joined #beagle
  • [09:33:47] <geckosenator> i'm coding lisp
  • [09:35:14] * aleij (n=ad@183-239.76-83.cust.bluewin.ch) has left #beagle
  • [09:35:24] <raster> run!
  • [09:35:39] * raster makes signs of warding
  • [09:48:10] * eFfeM (n=frans@195-241-226-180.ip.telfort.nl) has joined #beagle
  • [09:50:43] <koen> raster: include 'task-native-sdk' in your image, that should get you most of the way there
  • [09:50:51] <koen> and e-wm-dev
  • [09:52:11] * koen looks at The Cortex A8 CPU has an L2 cache preload engine (PLE) [1], which can
  • [09:52:14] <koen> be used to preload large blocks of data into the L2 cache. Using
  • [09:52:18] * koen stabs paste buffers
  • [09:52:24] * koen looks at http://elinux.org/BeagleBoard/contest
  • [10:00:47] * MostAwesomeDude (n=simpson@c-24-21-147-156.hsd1.or.comcast.net) Quit ("leaving")
  • [10:02:08] * MostAwesomeDude (n=simpson@c-24-21-147-156.hsd1.or.comcast.net) has joined #beagle
  • [10:09:54] * ldesnogu_ (n=ldesnogu@ven06-2-82-247-86-183.fbx.proxad.net) has joined #beagle
  • [10:12:24] * lcuk (i=lcuk@cpc1-oldh7-0-0-cust232.manc.cable.ntl.com) has joined #beagle
  • [10:13:08] <koen> heh
  • [10:13:22] <koen> gitweb sucks resources
  • [10:13:52] <koen> git.oe.net was being slow and bogged down, redirect gitweb to cgit and it's fast again
  • [10:14:02] <koen> and no 200 'git' processes running
  • [10:18:35] * abitos (n=nixgibts@dslb-084-057-155-064.pools.arcor-ip.net) has joined #beagle
  • [10:20:46] <ssvb> raster: pld instructions are not very useful for older ARM cores, ARM9E interpret them as nops, ARM11 r0pX cores have a bug which is workarounded by disabling HUM and this makes preloads useless too
  • [10:23:31] <ssvb> raster: does evas's 16bit engine use any ARM optimizations?
  • [10:25:51] <ssvb> raster: btw, if your code is compiled by gcc, you can just use __builtin_prefetch
  • [10:27:31] <koen> raster: could you see if http://dominion.thruhere.net/koen/OE/uImage-2.6.27-r12-beagleboard.bin solves your usbhost troubles?
  • [10:31:45] * erbo (n=Erik@c-7b7de455.115-16-64736c14.cust.bredbandsbolaget.se) has joined #beagle
  • [10:37:34] * valhalla (n=valhalla@81-174-24-85.dynamic.ngi.it) has joined #beagle
  • [10:37:42] <ssvb> raster: can evas use xrender/pixman as a backend?
  • [10:39:20] <koen> ssvb: it can with the 'xrender' engine
  • [10:40:01] <ssvb> koen: that's good, in this case there is no need to reinvent the wheel and all the optimizations should go to pixman
  • [11:14:34] * zuh eagerly awaits JITted pixman
  • [11:16:41] <ssvb> zuh: just improved armv6 and new neon optimizations should be enough
  • [11:17:18] <ssvb> zuh: in practice only a small subset of operations is used, and hand optimized code should be way better than jit for them
  • [11:18:59] * ScriptRipper (n=martin@85.233.34.53.dynamic.cablesurf.de) has joined #beagle
  • [11:20:24] <ssvb> zuh: doing a good registers allocation and instructions scheduling is a very challenging task for jit
  • [11:20:37] <ssvb> zuh: but I would be glad to be proven wrong
  • [11:21:04] <zuh> But someone still needs to do it :) I
  • [11:21:22] <ssvb> zuh: to do what?
  • [11:21:41] <koen> more recursion: http://scap.linuxtogo.org/files/e471710c23612b507f8b4a417f9aa15f.png
  • [11:21:46] <zuh> 'm not sure if JIT brings any easiness to it but doesn't seem like people are eager to do insane amounts of fast paths
  • [11:22:07] <zuh> for all possible combinations
  • [11:22:55] <ssvb> zuh: all the possible combinations are not so much needed, for example the browser only requires about a dozen of them
  • [11:23:18] <koen> zuh: I'd settle for a static compiler that outputs fast paths for stuff I use :)
  • [11:23:24] <koen> zuh: be it with NEON or not :)
  • [11:23:46] <zuh> But I just follow the thread at the cairo list, don't know much about JIT anyway so take my statements with a grain of salt...
  • [11:24:02] <ssvb> koen: you really don't want to do it, the amount of all possible permutations is insanely huge
  • [11:24:35] <ssvb> zuh: jit should be definitely better than falling back to unoptimized reference C code
  • [11:26:44] <zuh> Yeah, and if I get it right the point is that then you wouldn't need to do 'instruction set * op * src format * dest format' code paths, but slightly less of them :)
  • [11:27:23] <koen> zuh: I read daniels theses and his conclusion was "it's slower and need 3 seconds startup time"
  • [11:27:42] <zuh> Maybe he is wrong! :P
  • [11:27:44] <koen> ssvb: it would make pixman about 900kB bigger
  • [11:27:48] <ssvb> koen: sorry, I probably misread you, anyway static compiler is not a very good solution as it can't emit the very best code
  • [11:29:12] <ssvb> zuh: you also forgot transform and clipping settings, they add a bit to the number
  • [11:29:32] <zuh> right :)
  • [11:30:09] <zuh> koen: Btw, now that you brought NEON up, http://linux.onarm.com/bugzilla/show_bug.cgi?id=37
  • [11:30:10] * zedstar (n=john@fsf/member/zedstar) has joined #beagle
  • [11:32:08] <zuh> I guess those originate from mozilla...
  • [11:32:10] <ssvb> zuh: that's good to see some neon stuff getting developed
  • [11:33:06] <ldesnogu_> ssvb, aren't OpenGL/DirectX drivers basically a mixture of JIT and dedicated optimized paths (in that case HW accelerated)? I guess a mixed approach is the way to go
  • [11:33:27] <ssvb> ldesnogu_: that's exactly the point
  • [11:34:57] <ldesnogu_> zuh, this patch uses intrinsics, is that any good?
  • [11:35:00] <ssvb> ldesnogu_: what I wanted to say is that generic jit can't replace dedicated optimizations, and the browser for example can survive only with these dedicated optimizations as it does not need many of them
  • [11:35:17] <ldesnogu_> ssvb, I fully agree
  • [11:35:22] <zuh> ldesnogu_: I dunno, I haven't tried or even looked too much at it
  • [11:35:30] <ldesnogu_> I just meant to say that it's not enough a reason to dismiss JIT
  • [11:35:44] <ldesnogu_> first optimize by hand dedicated paths
  • [11:35:52] <ldesnogu_> then use JIT for the others :)
  • [11:36:07] <ssvb> ldesnogu_: yes, it most likely these neon optimizations are not very good
  • [11:36:09] <ldesnogu_> of course that will make developers crazy :p
  • [11:37:15] <ldesnogu_> I have seen LLVM will start adding SIMD support in their intermediate representation
  • [11:37:16] <ssvb> ldesnogu_: what is needed first is some kind of benchmarking and regression testing code which would allow to objectively judge the optimizations and help to keep only the best code
  • [11:37:40] <ldesnogu_> indeed :-(
  • [11:37:58] <ldesnogu_> and objective benchmarking is close to impossible
  • [11:38:16] <ldesnogu_> or too time consuming
  • [11:38:53] <ssvb> ldesnogu_: I have done some armv6 optimizations (not pushing them to extreme though) for Xomap on Nokia Internet Tablets, now it would be nice to merge them upstream
  • [11:39:37] * erbo (n=Erik@c-7b7de455.115-16-64736c14.cust.bredbandsbolaget.se) Quit ("...")
  • [11:40:09] <ssvb> ldesnogu_: it is possible to get some information about the typical use cases and base benchmarks on them
  • [11:41:30] <ssvb> ldesnogu_: for example it usually helps to know what is the typical input data (sizes of the pictures, percentage of zero values in alpha channel mask, etc.)
  • [11:42:11] * Xenion (n=robert@p579FC1A2.dip.t-dialin.net) has joined #beagle
  • [11:42:14] <ssvb> ldesnogu_: but getting completely objective results is nearly impossible
  • [11:42:24] <Xenion> hello
  • [11:42:27] <Xenion> jkridner, ? are you there ?
  • [11:43:27] <Xenion> koen, ?
  • [11:43:33] <koen> zuh: isn't that the patch with the colour corruption?
  • [11:43:42] <Xenion> ah hello koen
  • [11:43:47] <koen> hey Xenion
  • [11:44:17] <Xenion> i have a question regarding angstrom 2.6.26-omap1, my rndis interface isn't coming up :/
  • [11:46:11] * mib_phil (i=57ae0dd8@gateway/web/ajax/mibbit.com/x-4b84fbbd01f08d2c) Quit ("http://www.mibbit.com ajax IRC Client")
  • [11:46:21] <ldesnogu_> ssvb, plus add some people will use 24 bit colours, while others will use 16 bit ones; and what about HW acceleration? very complex task indeed
  • [11:46:25] <ssvb> koen: extensive regression testing is a must when developing complex optimizations which change a lot of code
  • [11:47:42] <ssvb> ldesnogu_: 24 and 16 bit cases are not a problem in the sense that they need separate implementations that are to be judged separately
  • [11:49:23] <ssvb> ldesnogu_: and I focused on 16-bit optimizations, they are much better for the browser if the desktop color depth is 16bpp
  • [11:50:26] <ssvb> ldesnogu_: unfortunately mozilla people don't think so and they always use 32bpp for all the intermediate rendering in fennec unless something has changed recently
  • [11:50:28] <koen> ssvb: Firefox3 does everything in 24bit and converts it to 16bit when rendering the pixmap to the screen
  • [11:50:35] <koen> heh
  • [11:50:36] * koen too slow
  • [11:51:24] <ldesnogu_> ssvb, I guess optimizing 16 bit specifically will bring more speedup than optimizing 24 bit, but not optimizing 24 bit will be a problem no?
  • [11:51:34] <kulve> is it much slower to run the X in 24bit mode too? More bandwidth is required but the conversion can be skipped?
  • [11:52:32] <ldesnogu_> kulve, I *guess* bandwidth is not the limiting factor here, though it's an important one
  • [11:52:39] <ssvb> kulve: this needs to be benchmarked, also 24bit pixmaps take more space in memory and that is another concern
  • [11:53:16] <Xenion> koen, is there any way to tell the BB to get RNDIS up ? i mean usb0 ?
  • [11:53:31] <ldesnogu_> ssvb, is it pixmaps that consume most of the memory in browsers?
  • [11:53:42] * FuL|OUT is now known as fulgas
  • [11:53:46] <kulve> I guess koen can run cairoperf in no time? ;) (if cairoperf tells enough about this situation)
  • [11:54:21] <ssvb> koen: that's about 16bpp vs. 24bpp: https://bugzilla.mozilla.org/show_bug.cgi?id=465042
  • [11:54:38] <koen> Xenion: 'ifup usb0' ?
  • [11:54:46] <Xenion> koen, done
  • [11:54:56] <koen> zuh, kulve, tomba: XV doesn't work for me: http://pastebin.com/f366d6d2a
  • [11:55:26] <ssvb> ldesnogu_: it depends on a webpage to be browsed of course, if the page is a huge image gallery, it does matter
  • [11:55:40] <kulve> koen: hmm.. I got the same couple of times
  • [11:55:51] <kulve> koen: what's your kernel args for omapfb?
  • [11:55:58] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has joined #beagle
  • [11:55:58] <Xenion> koen, my host pc isn't seeing any action from the BB ?
  • [11:56:21] <koen> kulve: root@beagleboard:~# cat /proc/cmdline
  • [11:56:22] <koen> console=ttyS2,115200n8 video=omapfb:vram:2M,vram:4M,mode:640x480@60 omapfb.debug=y omap-dss.debug=y loglevel=10 omapfb.vram=4M,4M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
  • [11:59:03] <lcuk> ssvb, mozilla people are thinking in terms of desktop gpu
  • [11:59:10] <ssvb> ldesnogu_: the bandwidth is the only factor if we are just blitting images without any blending, scaling or whatever else, this operation is quite often too
  • [12:00:17] <ssvb> lcuk: they at least used to be thinking in terms of desktop gpu :)
  • [12:00:54] <kulve> koen: I tried with there (but only on EVM): omap-dss.def_disp=dvi omapfb.video_mode=640x480MR-24@60 omapfb.debug=y omap-dss.debug=y loglevel=10 vram=10M
  • [12:01:22] <kulve> koen: I tried with -24 and -16. I didn't test much with the lcd as I would need it to be rotated..
  • [12:01:35] <lcuk> yeah, but as with many apps, taking old assumptions and working backwards is difficult (qt has same 32bit issues)
  • [12:01:58] <ldesnogu_> ssvb, I stand corrected :) is it also the case for text rendering? I guess characters are pre-rendered then blitted?
  • [12:02:54] <ssvb> ldesnogu_: text rendering is using antialiasing
  • [12:04:08] <ldesnogu_> hum I guess then it depends on the contents of the destination
  • [12:04:28] <ldesnogu_> it looks like browser benchmarking is even more complex than what I already thought :/
  • [12:05:05] <ssvb> ldesnogu_: the relevant functions for text rendering are fbCompositeSolidMask_nx8x8888/fbCompositeSolidMask_nx8x0565 and fbCompositeSrcAdd_8000x8000
  • [12:05:16] <lcuk> benchmarking is easy, acting on the results and making things better is hard
  • [12:05:43] <ssvb> ldesnogu_: they could be probably merged into something that works faster
  • [12:06:54] <ldesnogu_> lcuk, I've been benchmarking for years and I can tell you that even getting results is not easy
  • [12:07:54] <kulve> yeah, benchmarking "something" is easy. Benchmarking something that provides meaningful results is already more complicated
  • [12:08:01] <ldesnogu_> I've seen people collecting results in environments that were not meaningful at all
  • [12:08:21] <ldesnogu_> for instance forgetting that page sizes are 4 KB on most OS
  • [12:09:58] <ssvb> ldesnogu_: one of the common pitfall is to to initialize source buffer with something, the OS is clever enough to map all such buffer to a single empty page
  • [12:10:21] <ssvb> ldesnogu_: I mean "not to initialize" of course
  • [12:11:08] <ssvb> ldesnogu_: and the benchmark results are overly optimistic as the whole "source buffer" is perfectly cached
  • [12:11:30] <ldesnogu_> :)
  • [12:12:07] <ldesnogu_> so we basically all agree that good benchmarking is highly complex :)
  • [12:12:54] <mru> hi hackers
  • [12:13:07] <ldesnogu_> newbie question: how do the various libraries used in rendering interact with HW acceleration?
  • [12:13:15] <ldesnogu_> mru, hello :)
  • [12:13:33] <mru> badly, most likely
  • [12:13:34] <kulve> ldesnogu_: short answer: they don't :)
  • [12:13:41] <lcuk> depends specifically on the library and the motivations and design goal
  • [12:14:01] * mru has done hardware accelerated antialiased text rendering on broadcom stb chips
  • [12:14:03] <lcuk> and whether anyone with interest in accel has the time and skills to special case accel
  • [12:14:56] <kulve> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
  • [12:14:59] <kulve> that's one way
  • [12:15:31] * koen wonders when someone will update http://cgit.freedesktop.org/~pippin/cairo/
  • [12:15:42] <raster> koen: oh i will add - i just manually thrrew on pkgs for now
  • [12:17:32] <raster> ssvb: sorry was eating
  • [12:17:40] <ldesnogu_> well not taking into account HW accel looks bad :-(
  • [12:18:10] <ldesnogu_> and means that potentially all time spent on optimizing sw might be a waste
  • [12:18:11] <raster> koen: not checking uimage currently... busy getting this up as my dev sys
  • [12:19:24] <mru> btw, I see you guys were talking about the PLE a while ago
  • [12:19:29] <raster> ssvb: pld seemed to get speedups on armv5
  • [12:19:55] <raster> ssvb: and have a xrender engien - and i've already checked the neon patches
  • [12:20:16] <raster> as such evas's plain-old c rendering core (software) beats xrender hands down
  • [12:21:02] <ssvb> ldesnogu_: if the graphics drivers are closed source, it is a complete disaster as not much can be done about HW related optimizations or imprevements
  • [12:21:19] <ssvb> raster: was it some xscale armv5 chip?
  • [12:21:22] <raster> (44% lower average framerate than evas;'s software with dome paths being 1/10th the speed)
  • [12:21:34] <raster> with the neon patches xrender speeds up
  • [12:21:45] <raster> but only plain over unscaled alpha blends beat evas;'s software
  • [12:22:05] <ssvb> raster: what do you use for benchmarking?
  • [12:22:08] <raster> every other path is still slower
  • [12:22:21] <raster> by a big margin
  • [12:22:24] <ldesnogu_> raster, pld efficiency is not related to an architecture but rather a particular implementation of it
  • [12:22:47] <ldesnogu_> even an armv7 chip is free to ignore pld
  • [12:22:57] <raster> (average fps for evas software - 32bit internal engine converts to 16bpp rgb565 with dithering when writign to the screen - xrender using 32bpp pixmaps and writign to 16bpp window at the end)
  • [12:23:04] <raster> evas software gets 59.33 fps avg
  • [12:23:13] <raster> pxrender (without neon pixman) 33.05fps
  • [12:23:16] <raster> with neon - 38.89
  • [12:23:35] <ldesnogu_> ssvb, is that really a closed source vs open issue? I would rather say that it's a matter of getting an API
  • [12:23:38] <raster> ldesnogu_: hmm - interesting. must have been partitular to the armv5 in the n800
  • [12:23:40] <raster> particular
  • [12:23:49] <ldesnogu_> n800 is ARMv6 based
  • [12:23:52] <raster> ssvb: this yest is on a beagleboard - :)
  • [12:23:53] <ldesnogu_> arm1136
  • [12:24:00] <koen> nice, squashfs is in mainline (2.6.29rc1) now
  • [12:24:42] <raster> ssvb: and my benchamrer is expedite - the thing i always use as it directly tests paths in evas's rendering and instantly supports multiple back-ends renderers
  • [12:25:11] <raster> from opengl through to direct framebuffer, software rendering engines and xrender too - and others i dont much care about too
  • [12:25:12] <raster> :)
  • [12:25:26] <raster> ldesnogu_: hmm i though v5
  • [12:25:34] <raster> oh wait no - my zaurus is v5
  • [12:25:38] <raster> sorry - mixing up my devices
  • [12:25:39] <raster> :)
  • [12:26:03] <ssvb> raster: pld does not improve performance on n800 anymore :(
  • [12:27:13] <raster> really?
  • [12:27:22] <raster> well then - waste of time there
  • [12:27:38] <raster> but my main aim is to get some neon asm in the software core
  • [12:27:47] <raster> as i'm basically taking plain c code and throwing simd neon at it
  • [12:27:56] <raster> i am guessint i should average 50% speedups
  • [12:28:32] <raster> i'll do the simple stuff first - blit (memcpy), then over blends, then over+modulate, then tiem for the real fun - the scaler
  • [12:28:38] <raster> thats an evil bit of code there
  • [12:28:42] <raster> yuv->rgb too
  • [12:28:52] <lcuk> scalars arent evil, just suboptimal
  • [12:29:41] * lcuk curses his own bitmap scalar
  • [12:30:09] <ssvb> raster: yes, doing everything including scaling in one pass is a bit complex, but it's not so bad for the nearest neighbour scaling though
  • [12:30:25] <raster> lcuk: scaler you mean?
  • [12:30:45] <raster> ssvb: nearest neigthbour is trivial
  • [12:30:48] <raster> neigbour
  • [12:30:53] <raster> thats boring
  • [12:30:54] <lcuk> yeah, must have more coffee
  • [12:31:07] <raster> evas's "smooth" scaler is a full accurate super/sub sampling scaler
  • [12:31:08] <ssvb> raster: why do you need yuv->rgb?
  • [12:31:33] <raster> ie if 1 ouptu pixel covers 3.567x2.3445 input pixels
  • [12:31:38] <raster> it will correctly sample those
  • [12:31:44] <raster> with the correct offsets and weighting
  • [12:31:53] <raster> and vice-versa - interpolation too
  • [12:32:04] <raster> the c implementation is.. surpsiingly fast - considering whyat it has to do
  • [12:32:13] <raster> i have an mmx implementation of it too
  • [12:32:28] <raster> and yuv->rgb i need because i need to get rgb32 data for the pipeline
  • [12:32:36] <raster> video data is just another pixle data source
  • [12:32:50] <raster> it can be transformed and alpha blended (faded in and out)
  • [12:32:50] <ssvb> raster: how many points do you use for interpolation? is it some variant of bilinear scaler?
  • [12:32:56] <raster> with any numebr of objects layered on top
  • [12:33:00] <raster> (or drawn underneath)
  • [12:33:07] <raster> with any number of videos playing at once
  • [12:33:09] <raster> of any size
  • [12:33:26] <raster> for super-sampling (scaling down) i use all input points
  • [12:33:28] <raster> every single one
  • [12:33:30] <raster> no limit
  • [12:33:46] <raster> so scale 1000x1000 to 10x10 - every pixel will sample 100x100 src pixels
  • [12:33:59] <raster> (sum and divide by #)
  • [12:34:06] <ssvb> raster: isn't it slow?
  • [12:34:10] <raster> for upscaling its simpel linear - so 4 points
  • [12:34:15] <raster> ssvb: it can be slow
  • [12:34:24] <raster> but u'd be amazed how fast it is .. if you are smart about it
  • [12:34:34] <raster> i basically have just the sampling overhead
  • [12:34:42] <raster> weight calculation is done with a table
  • [12:34:56] <raster> ioncluding src offst/pointer calcs
  • [12:35:06] <raster> as that pre-calc is only done for the x then y axis for output
  • [12:35:13] <raster> the rest is just runing through the table
  • [12:35:18] <raster> :)
  • [12:36:05] <mru> raster: the scaler you describe sounds like it won't produce very good-looking results
  • [12:36:38] <mru> the proper way is to use a full sinc filter, but that's far too slow
  • [12:37:00] <raster> mru: u'd be surprised at the results
  • [12:37:06] <mru> a lanczos filter is almost as good and much faster
  • [12:37:06] <raster> its "mathematically" correct
  • [12:37:16] <raster> ie in that it'd take a correct source rectangle
  • [12:37:33] <mru> linear interpolation is of course "mathematically" correct in some sense
  • [12:37:38] <raster> we can forever discuss the gaussian distribution filters
  • [12:37:38] <mru> it just looks terrible
  • [12:37:51] <raster> the weighted curv sampling
  • [12:37:58] <raster> theres entire mountains fo reserahc papers on it
  • [12:38:08] <raster> but in the end... you quibble over tiny improvements
  • [12:38:17] <raster> the simple box filter produces realyl nice results
  • [12:38:21] <raster> in real life usage
  • [12:38:28] <mru> linear vs lanczos is not a tiny difference
  • [12:38:32] <raster> ooh for down or up scaling?
  • [12:38:37] <mru> doesn't matter
  • [12:38:42] <raster> it does
  • [12:38:45] <raster> different domains
  • [12:38:47] <mru> with downscaling you easily run into aliasing effects
  • [12:39:02] <lcuk> for all the years of research the end user will just move a slider till he finds a LOD hes happy with ;)
  • [12:39:10] <raster> possible with perfectly regular patterns
  • [12:39:47] <mru> you get aliasing as soon as the source has a frequency component above the nyquist frequency of the target
  • [12:39:54] <raster> yup
  • [12:39:55] <raster> i know
  • [12:40:03] <raster> your usual moire effects
  • [12:40:08] <mru> it doesn't have to be a regular pattern
  • [12:40:10] <raster> in reality - you almost never encouter that
  • [12:40:20] <mru> it just needs to have high-frequency components
  • [12:40:38] <mru> I've seen it many times with things like brick buildings
  • [12:40:59] <mru> or take a photo of an lcd monitor
  • [12:43:14] <raster> i know
  • [12:43:46] <raster> been doing gfx for long enouhg
  • [12:43:55] <mru> a downscaler that works on blocks independently will give strange effects around the block edges
  • [12:44:01] <mru> at least with "evil" inputs
  • [12:44:04] <raster> after doing it for a while i came to the conclusion that it didnt really matter a lot
  • [12:44:13] <raster> nearest was way too bad
  • [12:44:18] <mru> ugh
  • [12:44:19] <raster> but got that filter anyway
  • [12:44:26] <raster> for "speed"
  • [12:44:34] <mru> linear is only slightly slower
  • [12:44:43] <raster> i could have played games with gaussian distribution of sample points to avoid moiring etc.
  • [12:44:49] <raster> but that'd just slow stuff down
  • [12:45:01] <koen> raster: you also want 'task-proper-tools' if you want to run autoconf stuff
  • [12:45:04] <raster> i could limit the filter table to sampel at MOST NxM points when downscaling
  • [12:45:07] <raster> that'd not be hard
  • [12:45:15] <raster> but it wass simpler this way
  • [12:45:20] <raster> and the results were pretty nice
  • [12:45:20] <raster> :)
  • [12:45:28] <lcuk> you could just detect a moire pattern and put a sign over the top :D
  • [12:45:41] <raster> HAHAHAHHAHAHA
  • [12:46:41] <raster> koen: added them to the pkcg list
  • [12:46:45] <raster> (for now)
  • [12:47:03] <ssvb> mru: nearest scaler is always faster, its performance is comparable to memcpy
  • [12:47:19] <mru> I know it's fast
  • [12:47:19] <raster> mru: i was always banking on hardware pixking up the tab sooner or later
  • [12:47:25] <mru> but it's so ugly that it doesn't matter
  • [12:47:31] <ssvb> mru: agreed :)
  • [12:47:33] <mru> might as well use memset insteast
  • [12:47:34] <raster> and just turn up the asinotropic filtering value to 8 or 16
  • [12:47:36] <mru> instead
  • [12:47:39] <raster> and then let it do the nasties
  • [12:47:52] <raster> but the more time drags on - the more i despair of hw ever being "there"
  • [12:48:02] <raster> (consdierign the drivers in front of it)
  • [12:48:06] <JayFoxRox> is xfce working on the beagleboard already? if so, how would I install it?
  • [12:50:10] <raster> either way - the software engine doesnt DEFINE what "smooth" is - just that its smoother than nearest
  • [12:50:15] <raster> it doesnt much care
  • [12:50:28] <raster> thats up to the implementor (ie me) to care about quality (vs speed) tradeoffs
  • [12:52:00] <ssvb> ldesnogu_: about the closed source vs open issue, having API is fine until you hit a brick wall, for example if everything is more or less fine, but on some specific corner case the performance or reliability or whatever is horrible and you need to support this corner case too
  • [12:53:01] <ldesnogu_> ssvb, of course; no API is perfect :-) my point was just that closed source was not the real problem
  • [12:53:43] <_AV500_> mru, raster: on the BB you can also resize using the ISP resizer
  • [12:53:58] <_AV500_> should be faster for "large" images
  • [12:54:04] <mru> doesn't that only work with the camera input
  • [12:54:12] <_AV500_> nope, also mem2mem
  • [12:54:37] <_AV500_> actually since the DM270
  • [12:55:31] <_AV500_> there we had to toggle some ISP pin polarities to make the resizer believe it uses CCD input, but it was memory to memory :-)
  • [12:57:31] <raster> _AV500_: handles ARGB32?
  • [12:57:35] <raster> and with filtering?
  • [12:57:43] <raster> (ie not "nearest")
  • [12:57:53] <mru> it seems to have a 7-tap filter
  • [12:58:01] <_AV500_> filtering: yes of course, otherwise no use
  • [12:58:07] <raster> better than nothing
  • [12:58:09] <_AV500_> but not ARGB :-(
  • [12:58:15] <raster> aaah
  • [12:58:18] <raster> thats always the problem
  • [12:58:30] <raster> "not the format you want"
  • [12:58:35] <_AV500_> but in a media oriented product you alsways have lots of YUV to resize :-)
  • [12:58:43] <raster> depends
  • [12:58:51] <raster> to me yuv is "yet another pixel format"
  • [12:58:58] <raster> i guess i look at it much the way GL does
  • [12:59:02] <_AV500_> actuallly, it also handles mono, so you could to 4x resize
  • [12:59:11] <raster> its just source pixels.. going to a destination buffer and getting some transform along the way
  • [12:59:14] <mru> yuv is "yet another bunch of pixel formats"
  • [12:59:15] <_AV500_> but the decomp/recomp kills you
  • [12:59:17] <raster> and possibly being merged with dest buffer
  • [12:59:32] <raster> mru: true :)
  • [12:59:45] <raster> in all honesty - the neon will do the job
  • [12:59:55] <raster> i likely can keep the neon's memory bus accesses busy enough
  • [13:00:07] <mru> ldesnogu_: can we have like 8 neon units or something? please?
  • [13:00:10] <raster> in reality the sgx is the "right choice"
  • [13:00:16] <raster> and i'll worry about that after this neon fun
  • [13:00:31] <_AV500_> bbl, need to make a headache go away...
  • [13:00:46] <ldesnogu_> mru, yeah no problem, just add 6 cell batteries
  • [13:01:33] <ldesnogu_> mru, add that to your list on desirable NEON thingies, I'll see what I can do :)
  • [13:02:14] <Crofton|work> has anyone used root on NAND lately?
  • [13:02:15] <ldesnogu_> BTW it would be interesting to see what NEON lacks for 2d rendering
  • [13:02:28] <ldesnogu_> I guess wider vectors would be good
  • [13:02:50] <mru> 8x32 vectors would be nice
  • [13:02:50] <raster> ldesnogu_: eh?
  • [13:03:01] <raster> 128bits isnt enough?
  • [13:03:09] <raster> or do u mean 4x64?
  • [13:03:49] <raster> seriously tho i'd like a "high level mmu" in it
  • [13:03:56] <raster> or emore a way to remap pixel accesses
  • [13:04:00] <mru> at least in video processing you often have 8x16 data
  • [13:04:14] <raster> so basically u can feed an x,y in and the hw handles a translation ot an address
  • [13:04:30] <ldesnogu_> raster, MMU in NEON ?!?
  • [13:04:32] <raster> as basically i've been planning on doing tiled memory for srcdst data
  • [13:04:39] <raster> well not an "mmu"
  • [13:04:43] <raster> as in pageing
  • [13:04:47] <ldesnogu_> you mean a load engine?
  • [13:04:48] <raster> but a x,y -> address remapper
  • [13:04:50] <raster> yup
  • [13:05:01] <raster> but it can be "tought" to understand tiles
  • [13:05:03] <raster> err
  • [13:05:04] <raster> taught
  • [13:05:14] <raster> so insetad of data being linear with a simple stride
  • [13:05:24] <raster> its now a block ot tiles
  • [13:05:27] <raster> tiles havd trides
  • [13:05:28] <ldesnogu_> that's best left to dedicated chips
  • [13:05:29] <raster> err
  • [13:05:30] <mru> some kind of transpose instruction would be neat
  • [13:05:32] <raster> tiles have strides
  • [13:05:51] <raster> ldesnogu_: why only?
  • [13:05:54] <ldesnogu_> raster, ideally you want a smart hw prefetcher
  • [13:06:03] <raster> why then make the neon more powerful if thats best done by another chip? :)
  • [13:06:06] <ldesnogu_> not sth that has to be specifically programmed
  • [13:06:28] <ldesnogu_> raster, well in the end dedicated chips are better for low power :-)
  • [13:06:40] * ldesnogu_ gets ready for insults
  • [13:06:44] <raster> (and in reality though in theory that is right - in practice, until there are fully open drivers for the sgx - it's controversial to go building your entire world on it)
  • [13:06:44] <koen> all my beagles have a PSU :)
  • [13:06:49] <mru> but programmable is better for flexibility
  • [13:06:58] <koen> so I'd like a quad A9 + 32 neon units please :)
  • [13:07:06] <raster> ldesnogu_: *IG* sgx were open.. you'd have a very valid point - i'd agree
  • [13:07:24] <raster> but... to this day sgx is about as closed as it gets
  • [13:07:36] <mru> raster: get hired at imagination and leak the specs
  • [13:07:38] <mru> then run
  • [13:07:43] <raster> so i'm left with arm core, neon and dsp to play with openly
  • [13:07:43] <raster> :)
  • [13:07:51] <ldesnogu_> :)
  • [13:07:55] <raster> mru: that'd be too unethical for me :)
  • [13:08:03] <raster> i do believe in playing by the book
  • [13:08:04] <raster> :)
  • [13:08:14] <mru> I believe in rewriting the book
  • [13:08:20] <raster> hehehe
  • [13:09:10] <ldesnogu_> the alternative is reverse engineering img tec drivers and wait for 3 years to get first good results :)
  • [13:09:42] <raster> yup
  • [13:09:50] <raster> thus i am muhch more interested in neon and dsp
  • [13:09:56] <raster> alreayd have a gl enigne
  • [13:10:01] <raster> adapting to gl-es wont be hard
  • [13:10:35] <raster> but i would not bet my software or hw products on it
  • [13:10:59] <raster> i know enouhg vocal and influential open source people will never accept a closed driver
  • [13:11:12] <raster> so if its "use closed driver or the thnig doesnt work"
  • [13:11:28] <raster> then they will just say "wlel i wont use that device .. will i"
  • [13:11:40] <raster> and the problem is those hardliners are quite influential
  • [13:11:56] <raster> if u are targetting the joe schmo mass market its not relevant
  • [13:12:13] <raster> if u are targetting the oss developer/enthusiast market.. it can be a killer
  • [13:14:58] <ldesnogu_> raster, is really that radical crowd big enough a market?
  • [13:15:33] <ldesnogu_> don't get me wrong, I love oss, but I'm pragmatic :)
  • [13:15:55] <koen> ldesnogu_: the question is "is supportin closed-source drivers feasible for an FOSS company"
  • [13:16:16] <raster> ldesnogu_: what koen said
  • [13:16:25] <raster> if u wave the oss flag
  • [13:16:29] <raster> and use that to attract users
  • [13:16:32] <raster> then you play the game
  • [13:16:39] <raster> it is a market
  • [13:16:41] <raster> as i said
  • [13:16:44] <raster> the "radicals" are few
  • [13:16:46] <raster> BUT
  • [13:16:48] <Crofton|work> raster, just make the dsp work :)
  • [13:16:49] * koen was getting at the technical side of support
  • [13:16:53] <raster> they are often looked up to and highly influential
  • [13:17:04] <raster> Crofton|work: thats on my list of thigns to play with
  • [13:17:14] <raster> tho frankly the neon is probably going to be all i really need
  • [13:17:15] <raster> :)
  • [13:17:22] <ldesnogu_> ok let's put that differently: what made ubuntu more successful than debian?
  • [13:17:41] <koen> suppose I switch to hardfloat, will the imgtec drivers still work?
  • [13:17:50] <ldesnogu_> I might be wrong but isn't ubuntu more opened to non oss stuff?
  • [13:17:53] <Crofton|work> dsp is on my list, but I have to keep beating down fires
  • [13:17:58] <koen> when ARM switches to QABI, will the drivers still work, etc
  • [13:18:25] <koen> ldesnogu_: ubuntu allows evil stuff, yes, if you want something 'free' try gNewsense
  • [13:18:27] <raster> ldesnogu_: theres a difference
  • [13:18:29] <ldesnogu_> oh please don't make me say what I didn't
  • [13:18:31] <raster> if ubuntu said
  • [13:18:31] <Crofton|work> ldesnogu, we have to keep reminding people that closed source stuff is not a long term solution
  • [13:18:32] <koen> or 'gnonsense' as I call it
  • [13:18:57] <ldesnogu_> ok I stop talking about that
  • [13:19:00] <raster> "out ui only is compiz and thus all users must use a closed nvidia driver or ati driver)
  • [13:19:19] <koen> I wish compiz would support GLES :)
  • [13:19:26] <raster> (i will for now ignore the intel and open ati drivers etc. as it is different when you hardware target is a vast array of possible targets")
  • [13:19:42] <raster> and then people were forced to use the nvidia closed drivers or go use some other product
  • [13:19:52] <raster> i bet u i'd barely have gotten offthe ground
  • [13:20:05] <Crofton|work> ldesnogu, at times, some of us will compromise, but by doing that, we risk future apin
  • [13:20:07] <Crofton|work> er pain
  • [13:20:40] <raster> rememebr i was talking about basing the whole thing on the sgx
  • [13:20:41] <raster> ie
  • [13:20:45] <zuh> ldesnogu_: The non-multiyear release cycle, aiming to get stuff working out-of-the-box etc. :) Ubuntu has a drive to provide a user experience, while debian is more just a collection of software bundled together IMO.
  • [13:20:50] * mib_a9uvhg (i=5cec55b9@gateway/web/ajax/mibbit.com/x-a478b52d043868f4) has joined #beagle
  • [13:20:51] <raster> use the sgx or its "produce off"
  • [13:20:59] <ldesnogu_> Crofton|work, so in the hope to get a brighter future you compromise your actual development
  • [13:21:08] <raster> as you set your expectations for hw accel at a level wehre if it doesnt exist - the ui is useless
  • [13:21:26] <raster> i will not BET an entire ui on the sgx
  • [13:21:42] <Crofton|work> by using closed source material
  • [13:21:48] <raster> i will look at it as a "possible nice bit of extra candy for those willing to accept a closed driver in return for some more fps"
  • [13:21:49] <kulve> zuh: don't go there..
  • [13:21:54] <raster> thats as far as i will go
  • [13:22:21] <raster> and as already sed
  • [13:22:25] <raster> oabi->eabi,
  • [13:22:26] <ldesnogu_> the obvious conclusion for Beagle is: don't use OpenGL ES
  • [13:22:27] <raster> ebai->qabi
  • [13:22:31] <raster> or god knows what else
  • [13:22:43] <zuh> kulve: I'd ask if you could argue against that comment, but you'd do so regardless ;)
  • [13:22:47] <raster> ldesnogu_: no - its "use it very judiciously and with care"
  • [13:22:57] <raster> not just bet the farm on the sgx
  • [13:23:05] <raster> example
  • [13:23:08] <raster> clutter
  • [13:23:12] <raster> it's bet the farm on gl-es
  • [13:23:24] <raster> thus in the omap3 context its bet the farm on closed drivers
  • [13:23:42] <raster> until someone writes a software gl thats fast enough to be usable
  • [13:23:55] <raster> it is basically a "dont even bother" unless you will accept closed drivers
  • [13:24:00] <raster> that is a problem (imho)
  • [13:24:00] <kulve> the drivers are opne. The opengl es stack is closed
  • [13:24:10] <raster> i am very happy to see intel and now amd/ati doing open drivers
  • [13:24:18] <raster> s3/via as well have gotten in on it
  • [13:24:29] <raster> kulve: i consider the gl stack part of the drviers
  • [13:24:54] <raster> as until they specify the register locations and formats,. command queue implementation detaisl so someone can write a libGL of their own
  • [13:24:54] * jsync (n=jess@de3-as6677.alshamil.net.ae) has joined #beagle
  • [13:25:06] <raster> libGL is just a "userspace driver in a shared lib"
  • [13:27:32] <ldesnogu_> raster, I am glad some gfx vendors opened their specs; but that doesn't change what I buy now for my PC, nVidia. I will reconsider my position when OSS based on these specs are available, stable and give good performance
  • [13:28:10] <lcuk> or when graphics hardware improves so much that you can throw sloppy software at it and still get good results
  • [13:28:13] <raster> the problem is
  • [13:28:18] <raster> nvidia will resleas eno SPECS
  • [13:28:25] <raster> and imgtec wont either
  • [13:28:31] <raster> so it will never exist until they do
  • [13:28:54] <raster> and this is a personal opinion of yours
  • [13:29:00] <raster> guess what video card i have on my desktop?
  • [13:29:03] <raster> and what drivers?
  • [13:29:12] <raster> my point is not a presonal opinion of yours, or mine
  • [13:29:12] * tanatos (i=tanatos@gateway/shell/rootnode.net/x-06c16a2c995689c2) Quit (SendQ exceeded)
  • [13:29:25] <raster> there is a sizable and invluential group who will not do such a thing
  • [13:29:45] <raster> and there is a forward support danger if all you have is a binary
  • [13:30:08] <raster> and currently the libGL.so for sgx .. is not freely redistributable as best i know
  • [13:30:27] <mru> given the lifetime of graphics hardware I have no problem at all buying nvidia cards
  • [13:30:31] <mru> they work *now*
  • [13:30:45] <mru> if they stop working, I'll buy something that works then
  • [13:30:58] <raster> mru: ie - change vendor
  • [13:31:02] <raster> right?
  • [13:31:08] <mru> possibly
  • [13:31:27] <raster> so if u are a vendor where the gfx unit is totally inseparable from the device
  • [13:31:34] <mru> so far nvidia has a good record of keeping support for old cards with the latest kernel and X versions
  • [13:31:36] <raster> you will probably cease buying that vendor
  • [13:31:44] <raster> sure
  • [13:31:45] <mru> if that were to change I'd gladly replace any old cards I might have
  • [13:31:46] <raster> nvidia does
  • [13:31:51] <koen> raster: "select icons to add" :)
  • [13:31:59] <raster> and u can just replace the card if they do one day piss you off
  • [13:32:11] <koen> raster: does that check if .desktop files exist for the icons?
  • [13:32:20] <mru> if next time I'm buying a graphics card, ati is better in some way, I'll use that
  • [13:32:32] <raster> (i was burnt by ati's promise of good drivers and vowed never to touch ati again - for years i dealt with their garbage fglrx goop and never again will i touch that stuff)
  • [13:32:45] <raster> koen: yup - it does
  • [13:32:54] <raster> it looks for .desktops that run that command
  • [13:33:05] <raster> if found - they will not be there in the list as its already installed
  • [13:33:07] <koen> I didn't know mplayer had a .desktop :)
  • [13:33:14] <mru> ati used to have open specs, and there were good open-source drivers
  • [13:33:21] <mru> then they closed the specs, and made shit drivers
  • [13:33:29] <raster> does on my desktop in ubuntu
  • [13:33:31] <raster> :)
  • [13:33:35] <ldesnogu_> raster, I was told by a GPGPU guy that latest ATI drivers on Linux don't even deliver the results printed in their tutorials
  • [13:33:40] <mru> now they've opened the specs, but open-source drivers have a lot of catching up to do
  • [13:33:47] <raster> mru: yup. that is a good example of closed really screwing people
  • [13:33:56] <mru> nvidia has always been closed
  • [13:34:02] <mru> they used to also do shit closed drivers
  • [13:34:19] <raster> well actually up to rage128 it was open
  • [13:34:25] <mru> but for many years now, their drivers have been quite good
  • [13:34:27] <raster> but nv are good
  • [13:34:36] <raster> but who knows with imgtec
  • [13:34:50] <raster> they hjave no long standing history of support for linux and their now hybrid open/closed model
  • [13:34:58] <raster> i will not bet the farm on them
  • [13:35:12] <mru> it's a hybrid the same way nvidia is
  • [13:35:16] <raster> ldesnogu_: i know - they are catching up
  • [13:35:26] <raster> mru: i know - very similar model
  • [13:35:26] <koen> raster: slight bug: http://scap.linuxtogo.org/files/6356aec28b38151d2537675ee2d63bbd.png
  • [13:35:27] <mru> there's an open glue layer that can be compiled against any kernel/X
  • [13:36:03] <raster> koen: hmm not really a bug more as a "the way things are laid out it will be scrollable in all directions"
  • [13:36:04] <mru> then there's arm, going all secretive about v7...
  • [13:36:16] <raster> some really long label is making it wide
  • [13:36:26] <raster> but the parent wont expand that holds the scrolview
  • [13:36:32] <raster> as its got a fixed width
  • [13:36:35] <mru> automatic gui layouts suck
  • [13:36:45] <raster> i reall yliked the tall thn look for it
  • [13:36:53] <raster> but in this case it doesnt work too well
  • [13:36:54] <mru> actually, most guis suck
  • [13:36:56] <ldesnogu_> raster, they're not catching up; I am talking about recent added functionality (their GPGPU environment); so they keep on adding shit
  • [13:36:57] <raster> so i havent solved it yet
  • [13:37:25] <koen> raster: s:\ :\n:g in all labels internally?
  • [13:37:48] <raster> koen: hard - theme doesnt support textblock for the label
  • [13:38:00] <raster> tb also makes life hard for calculating min size as now things can wrap
  • [13:38:04] <ldesnogu_> mru, yes the v7 situation is unfortunate, but hopefully that will change
  • [13:38:10] <raster> and that means as widht schinks, height increases
  • [13:38:21] <raster> so u cant say "give me the min size of this"
  • [13:38:22] <raster> as its unknown
  • [13:38:22] <raster> :)
  • [13:38:32] <raster> its a lot trickirer than it seems
  • [13:38:48] <mru> ldesnogu_: it could be worse. at least I got the documentation when I asked for it
  • [13:38:58] <raster> ldesnogu_: chances are that benchmarks will force the speed to be fixed
  • [13:38:59] <mru> and now that people know me, it's much easier to get stuff
  • [13:39:25] <ldesnogu_> mru, you made it sound as if it was easy; you can't imagine how many mails I had to send :-)
  • [13:39:26] <raster> as in the gl works your fps ratign in quake4/ut/whatever is the all important measurment of your worth :)
  • [13:39:38] <mru> ldesnogu_: thanks for doing that
  • [13:39:59] <raster> ldesnogu_: i didnt even ask for my armv7 docs
  • [13:40:07] <raster> they were offered to me out of the blue
  • [13:40:09] <raster> :)
  • [13:40:12] <mru> raster: when?
  • [13:40:15] <ldesnogu_> I think it was good for everyone, given that it helped Crofton|work get the doc without me asking for it :)
  • [13:40:19] <raster> hmm a week ago or so
  • [13:40:24] <raster> i have to say thubms up to arm
  • [13:40:28] <raster> :)
  • [13:40:28] <mru> ah, there's the difference
  • [13:40:38] <mru> my battle was back in june
  • [13:40:39] * Crofton|work agreed
  • [13:40:44] <raster> aaah
  • [13:40:45] <raster> ok
  • [13:40:59] <ldesnogu_> that's why I say things are getting better :-)
  • [13:41:04] <koen> "thumbs up"
  • [13:41:25] <mru> thumb2 up
  • [13:41:28] <koen> worst
  • [13:41:29] <koen> pun
  • [13:41:31] <koen> ever
  • [13:41:34] <ldesnogu_> thumb is awful :D
  • [13:41:36] <raster> :-P~
  • [13:41:53] <mru> and of course a big thumbs up to TI for making the beagle board and opening their specs
  • [13:42:14] <raster> hmm
  • [13:42:15] <ldesnogu_> is it now that we again should thumb down imgtec? :)
  • [13:42:17] <raster> actually a bit of a q
  • [13:42:22] <raster> did ti actuall ymake it
  • [13:42:25] <mru> the fools at work think thumb mode is a good idea
  • [13:42:25] <raster> or just heavily support it
  • [13:42:31] <raster> i thought it was made independently?
  • [13:42:40] <mru> I switched the build to arm mode and everything got much faster
  • [13:42:40] <ldesnogu_> mru, re-educate them
  • [13:42:42] <koen> raster: TI designed, made by some fab
  • [13:42:47] <mru> ldesnogu_: that's not possible
  • [13:42:55] <raster> ldesnogu_: i am encouraged by imgtec releasing partl open drivers - at all
  • [13:43:07] <raster> as opposed to nada until you throw a large bucket of cash at them
  • [13:43:08] <raster> its a step
  • [13:43:22] <raster> and thats encouraging
  • [13:43:36] <koen> large bucket indeed
  • [13:43:36] <raster> but i'm not betting the farm on them yet
  • [13:43:55] * koen tries to work out how big the buckets needs to be
  • [13:43:58] <raster> koen: yup. i was actually wondering how i;'d get them until i kenew they were coming out in the open
  • [13:44:08] <Crofton|work> I think it would be helpful having open code using NEON and DSP
  • [13:44:21] <raster> ie i'd have to use my usual powers of pursation to snarf an "illegal copy" for just my own development
  • [13:44:21] <raster> :)
  • [13:44:21] <Crofton|work> as that may redcue demand for imgtec part
  • [13:44:37] <raster> koen: aaah ok. ti design
  • [13:44:40] <mru> koen: have you heard of the Sirius Star?
  • [13:44:51] <Crofton|work> sdadly, I do not think you can get a part with dsp and no imgtec
  • [13:44:51] <koen> mru: the oil rig?
  • [13:44:58] <mru> tanker
  • [13:45:08] <Crofton|work> the hijacked one?
  • [13:45:12] <raster> Crofton|work: 3525
  • [13:45:18] <Crofton|work> ah
  • [13:45:19] <koen> Crofton|work: isn't the 3525 the one you want?
  • [13:45:20] <raster> dsp + arm., no sgx
  • [13:45:21] <Crofton|work> good :)
  • [13:45:25] * koen too slow again
  • [13:45:26] <raster> :)
  • [13:45:37] <raster> i already looked and went "hmm now thats a possibility"
  • [13:45:41] <Crofton|work> need to ask sakoman to create an overo with that
  • [13:45:47] <raster> if i were doing a product
  • [13:45:57] <raster> i'd consider offering versions
  • [13:46:02] <raster> one with 3530 with higher cost
  • [13:46:19] * aleij (n=ad@183-239.76-83.cust.bluewin.ch) has joined #beagle
  • [13:46:20] <raster> and 3525 - cheaper for those less inclined to care or be much more hard-line
  • [13:46:42] <raster> as such i intend all of my ui stuff to work and work WELL - ie beautifully, without the sgx
  • [13:46:46] <Crofton|work> ming you, we have cerrtain "issues" with the dsp also :)
  • [13:46:49] <raster> as such so far on my bb - it's encouraging
  • [13:46:56] <raster> without any neon.. the stuff is smooth and nice
  • [13:47:12] <mru> speaking of the overo, does anyone know if it exposes the camera input?
  • [13:47:12] <raster> at least at the resolutions/pixel counts i intend to use
  • [13:47:27] <koen> raster: parts of IVA are still closed as well
  • [13:48:08] <mru> jkridner reckons if we do something neat with the dsp, we'll have a better case for opening the remaining parts
  • [13:48:16] <Crofton|work> but we hacve a shorter path to the people that need beating for dsp stuff
  • [13:48:20] <mru> they can only be accessed by the dsp after all
  • [13:48:24] <raster> koen: the isp?
  • [13:48:33] <raster> (video /camera handling etc.)
  • [13:48:34] <raster> ?
  • [13:48:39] <koen> mru: "Connector J5 on Overo - features the camera control signals."
  • [13:48:50] <raster> mru: i am thinking of doing somethnig with the dsp
  • [13:48:57] <raster> probably tryng to turn it into a ad-hoc gpu
  • [13:49:05] <koen> raster: there's much more advanced stuff, of which the *name* can't even be uttered in public :)
  • [13:49:05] <raster> ie be able to throw pixel blobs at it
  • [13:49:11] <raster> and it hands them back "worked on"
  • [13:49:23] <raster> koen: aaah
  • [13:49:27] <mru> the "video hardware accelerator"
  • [13:49:31] <raster> well for now i'm focusing on neon/arm
  • [13:49:40] <raster> then will see what i can swizzle the dsp into doing
  • [13:50:34] <mru> consisting of the iVLC, iME, and iLF
  • [13:50:46] * aleij (n=ad@183-239.76-83.cust.bluewin.ch) has left #beagle
  • [13:50:47] <raster> actually i need to ask
  • [13:50:51] * Leon_Nardella (n=leon@200-161-14-111.dsl.telesp.net.br) has joined #beagle
  • [13:50:55] <koen> I'd like to see 'drivers' for all the image processors (iMe, iLF, etc) for the omaps and davincis
  • [13:51:15] <mru> the 3530 trm doesn't even mention what the "video hardware accelerator" contains
  • [13:51:20] <mru> the 3430 trm does
  • [13:51:27] <koen> iirc TI released a codec-engine lib to access parts of those
  • [13:51:37] <raster> http://www.celinux.org/elc08_presentations/TI_OMAP3430_Linux_PM_reference.ppt
  • [13:51:42] <mru> but then you have to use dsplink
  • [13:52:11] <raster> in there ti allude to having basically brought down power consumption when itlde to what to me seems about 1.35mw
  • [13:52:18] <raster> and having all the cpufreq scaling working
  • [13:52:24] <raster> are those patches in oe's kernels yet?
  • [13:52:39] * docelic_ (n=docelic@78.134.198.111) Quit (Read error: 110 (Connection timed out))
  • [13:53:05] <koen> raster: most of those patches will be when Crofton|work pushes the -pm recipe :)
  • [13:53:12] <raster> aaaah
  • [13:53:15] <raster> so in the pipeline
  • [13:53:33] <raster> i'd love to see those out there
  • [13:53:35] <koen> raster: basically: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=pm-next
  • [13:53:40] <raster> at least by my calculations
  • [13:53:40] <Crofton|work> we have a recipe that builds from khilmans linux-omp-pm tree
  • [13:53:43] <raster> at 1.3mw
  • [13:53:46] <raster> who cares about suspend
  • [13:53:47] <raster> :)
  • [13:53:51] * docelic_ (n=docelic@78.134.199.40) has joined #beagle
  • [13:54:01] <raster> (thats what it looks like anyway)
  • [13:54:19] <koen> raster: but *everything* is like this: #ifdef BOARD_SDP3430 .. generic omap3 pm stuff .. #endif
  • [13:54:39] <raster> oh thats just silly!
  • [13:54:47] <koen> it's TI coding style
  • [13:55:01] <mru> is the C preprocessor turing-complete?
  • [13:56:38] <raster> well then all i need to do is work on userspace playing nice with remaining as idle as possible
  • [13:56:38] <raster> :)
  • [13:57:58] <Crofton|work> cpufreq I can look at on the place I hope
  • [13:58:07] <Crofton|work> well, if I can operate the computer
  • [13:58:21] * Crofton|work curses his crappy eyes and small airplane seats
  • [13:58:38] <raster> aaah
  • [13:58:40] <raster> that would make life suck
  • [13:58:49] <Crofton|work> yeah
  • [14:01:57] <koen> Crofton|work: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commitdiff;h=587221572c83442cbff813997dbc5de72a3fd5ed
  • [14:03:21] <mru> Crofton|work: are you thinking of attempting to work on an east-bound flight?
  • [14:03:26] <mru> that's not possible
  • [14:04:11] <Crofton|work> west
  • [14:04:22] <mru> another matter entirely
  • [14:04:30] <Crofton|work> koen, what aer you thinking that does?
  • [14:04:36] <mru> Crofton|work: where do you live?
  • [14:04:42] <Crofton|work> stop you from doing power saving while on serial console?
  • [14:04:49] <Crofton|work> Blacksburg, VA
  • [14:04:52] <koen> Crofton|work: restrict C states, iirc it has a 5 seconds backoff
  • [14:05:05] <koen> Crofton|work: which is the same as the powertop one
  • [14:05:08] <Crofton|work> I have 30 second powertop updates
  • [14:05:16] * mru has flown to and from CA a few times
  • [14:05:22] <mru> and .kr
  • [14:06:28] <raster> fly singapore
  • [14:06:32] <raster> take the a380
  • [14:06:38] <raster> gorgeous plane
  • [14:06:42] <raster> excellent food and service
  • [14:06:49] <mru> and the price?
  • [14:06:53] <raster> good looking stewardesses
  • [14:07:02] <mru> now you're talking ;-)
  • [14:07:04] <raster> and 110v ac power plugs in every seat in economy
  • [14:07:14] <raster> price - often one of the cheapest
  • [14:07:18] <mru> the korean air staff ain't bad looking either...
  • [14:07:21] <raster> if not the cheapest
  • [14:07:26] <raster> not bad
  • [14:07:30] <raster> but singapore beat them
  • [14:07:37] <raster> in quality of plane, food, service
  • [14:07:38] <mru> but they don't fly to korea
  • [14:07:48] <raster> and most of the time, price too
  • [14:07:51] <raster> they do
  • [14:07:57] <raster> u just have to fly via singapore
  • [14:07:57] <raster> :)
  • [14:07:58] <mru> if I want to go to korea I have two choices, korean air or asiana
  • [14:08:01] <raster> thats fine
  • [14:08:03] <mru> both good
  • [14:08:07] <raster> u get to stop at the new termnal3
  • [14:08:11] <raster> in changi airport
  • [14:08:26] <raster> that is probably the best terminal to waste time in while in transit
  • [14:08:27] <mru> the direct flight already takes over 11 hours
  • [14:08:33] <mru> I'm not going to extend that if I can avoid it
  • [14:08:37] <raster> lots of good food
  • [14:08:39] <raster> chopping
  • [14:08:41] <raster> free internet
  • [14:08:46] <raster> err shopping
  • [14:08:53] <mru> that's something I like about asia, the free internet
  • [14:08:56] <raster> comfy places to sit back and relax and stretch after the flight
  • [14:09:05] <mru> kansai airport even had ethernet sockets
  • [14:09:13] <mru> and power of course
  • [14:09:16] <raster> but then again i've bene flying syd <-> icn
  • [14:09:20] <raster> or sg <-> tpe
  • [14:09:24] <raster> or syd <-> hk
  • [14:09:35] <raster> or syd <-> nrt
  • [14:09:54] <mru> ah, you're in au
  • [14:09:55] <raster> so singapore on the way isnt muhc of a problem
  • [14:09:56] <mru> didn't know that
  • [14:09:57] <raster> yeah
  • [14:10:03] <raster> thats why i get the a380 flight
  • [14:10:13] <raster> first a380 flights were syd<->sin
  • [14:10:16] <raster> still are
  • [14:10:16] <raster> :)
  • [14:10:17] * Vij (i=75c0654d@gateway/web/ajax/mibbit.com/x-6937dfec4ac97301) has joined #beagle
  • [14:10:30] <mru> uk ain't a bad place to be for flights though
  • [14:10:35] <raster> singapore is my favorite airline
  • [14:10:37] <mru> direct flights to most places
  • [14:10:38] <raster> by a country mile
  • [14:10:48] <raster> not syd
  • [14:10:56] <raster> always bouncing thru asia somewhere
  • [14:11:05] <raster> but not too bad
  • [14:11:05] <mru> yeah, true
  • [14:11:20] <raster> as thats generally half a long flight anyway
  • [14:11:23] <mru> it's to make it harder for all the criminals we sent there to come back
  • [14:11:28] <raster> eg going to europe - there is no direct flight
  • [14:11:29] <raster> too far
  • [14:11:37] <raster> u have to stop somewhere to refuel
  • [14:11:49] <raster> so u end up stopping - and that doubles with bouncing thru asia
  • [14:11:50] <raster> :)
  • [14:11:57] * Crofton|work notes that his .au relatives are not descended from criminals
  • [14:12:02] <Crofton|work> well, I think
  • [14:12:11] <raster> mru: HAHAHA this crimnal cant be held down :")
  • [14:12:25] <raster> these days i'ts a free for all
  • [14:12:26] * mru uses "we" as though he were actually british
  • [14:12:28] <raster> sinc ei have a german passport
  • [14:12:29] <Vij> hi
  • [14:12:33] <raster> your country is mine for the taking
  • [14:12:35] <raster> MUAHHAHAHAHA
  • [14:12:36] <raster> :)
  • [14:12:49] <mru> raster: "my country" is a bit complicated
  • [14:13:07] <raster> well lets assume "my country" for now is the uke - i where you are :)
  • [14:13:14] <raster> "my country" is also complex
  • [14:13:20] * Vij (i=75c0654d@gateway/web/ajax/mibbit.com/x-6937dfec4ac97301) Quit (Client Quit)
  • [14:13:24] <mru> I live in the uk but travel with SE and US passports
  • [14:13:26] <raster> it generally tends to just be wherevere i'm hanign my hat at the time
  • [14:13:27] <Crofton|work> it is a complex world
  • [14:13:38] <raster> mru: i've been similar
  • [14:13:41] <raster> .de and .au passports
  • [14:14:00] <raster> i've lived in .ng, .de, .au, .jp and .tw
  • [14:14:08] <raster> or and .us as well
  • [14:14:23] <raster> i totally get where you're at :)
  • [14:14:50] <mru> you're worse than me
  • [14:15:00] <mru> I've only lived in .se, .no, and .uk
  • [14:15:23] <mru> thinking of moving to .net next
  • [14:15:52] <raster> HAHAHHAHAHAHAHAHA
  • [14:18:57] <lcuk> raster, do you actually laugh like that in RL?
  • [14:19:11] <raster> lcuk: in capitals ? :)
  • [14:19:36] <Xenion> hey guys
  • [14:19:41] <lcuk> heh yeah
  • [14:19:56] <Xenion> what about "could not set configuration" ? .. i'm trying to reflash uboot to my BB
  • [14:20:11] <Xenion> http://elinux.org/BeagleBoardRecovery#USB_recovery
  • [14:20:20] <Xenion> but i'm stuck at the error stated above
  • [14:20:38] <raster> lcuk: if its funny - yes :) i dont titter like a japanese schoolgirl
  • [14:20:42] <raster> though if you want - i kan
  • [14:20:44] <raster> err can
  • [14:21:04] <mru> japanese schoolgirls.... say no more
  • [14:21:06] <raster> ????????????????????????????????????
  • [14:21:09] <koen> uh oh
  • [14:21:21] <koen> zrusin and raster are going to be in the same room again
  • [14:21:35] <raster> ??????????????????
  • [14:21:39] <raster> :)
  • [14:21:49] <mru> raster: do you speak japanese?
  • [14:21:57] <raster> mru: ??????
  • [14:22:05] * mru doesn't read japanese
  • [14:22:15] <mru> at least not those symbols
  • [14:22:17] <raster> ??????????????????????????????????????????
  • [14:22:17] <Xenion> Texas Instruments X-Loader 1.41
  • [14:22:17] <Xenion> Starting OS Bootloader...
  • [14:22:27] <Xenion> my system is hanging on this prompt
  • [14:22:34] <raster> mru: lived in tokyo for 4 years
  • [14:22:40] <mru> raster: "japan..." is as far as I get with that
  • [14:22:41] <raster> so yes- i can get around with japanese
  • [14:22:56] <raster> as i learnt my japanese from girls
  • [14:23:00] <mru> I've only been to japan twice
  • [14:23:05] <raster> i can nicely immitate them
  • [14:23:10] <raster> so i speak like a little girl
  • [14:23:15] <Crofton|work> koen, we have a pm recipe now
  • [14:23:23] <raster> in japanes ethe language is vastly different for males and females
  • [14:23:32] <mru> so I've gathered
  • [14:23:35] <raster> so apparently its very amusing for the japanese to hear me talk like a girl
  • [14:23:42] <raster> as it just is totally odd
  • [14:23:48] <raster> this guy who is much bigger and taller than them
  • [14:23:51] <koen> Crofton|work: yay!
  • [14:23:59] <raster> likely can crush them in a single hand
  • [14:24:00] <koen> Crofton|work: I'm adding ubifs support to OE :)
  • [14:24:02] <Crofton|work> I suspect it will need help
  • [14:24:07] <raster> talks like a teenage girl
  • [14:24:15] <raster> and that just gets them laughing away
  • [14:24:16] <raster> :)
  • [14:24:41] <Crofton|work> koen, great
  • [14:24:55] <raster> you end up learning from girls because its so much easier to learn and understand
  • [14:24:56] <Crofton|work> I have a feeling I'll need root on nand soon
  • [14:25:21] <raster> Crofton|work: that will mean for sanity.. nand speed is going to have to come up to something usable
  • [14:25:22] <raster> :)
  • [14:25:30] <mru> girls can be a great motivating factor...
  • [14:26:36] <raster> hahahahaha
  • [14:28:47] * ClaudeQC (n=claude@bas1-quebec03-1279635522.dsl.bell.ca) has joined #beagle
  • [14:32:30] <jkridner> good morning alll
  • [14:32:37] <mru> morning jkridner
  • [14:32:56] <Xenion> hello jason ( jkridner ) :-)
  • [14:33:08] <ClaudeQC> Good morning
  • [14:33:16] <jkridner> anyone able to run the u-boot musb code?
  • [14:33:57] <koen> haven't tried
  • [14:34:03] <mru> me neither
  • [14:34:04] <jkridner> Xenion: you might need to remind me if I know who you are, because it'd be good to know you.
  • [14:34:11] <koen> jkridner: the uboot binary you gave me still tends to ignore env in nand :(
  • [14:34:29] <Xenion> jkridner, i know that feeling :-)
  • [14:34:31] <jkridner> I tried, but I saw some serial output from it only once. then I couldn't get it to repeat.
  • [14:34:55] <jkridner> koen: yeah, I fixed the wrong entry.
  • [14:35:12] <koen> jkridner: don't forget to update the 'sum points' in http://elinux.org/BeagleBoard/contest when you're done ranking
  • [14:35:13] <jkridner> try http://www.beagleboard.org/~arago/u-boot-flash.bin
  • [14:35:24] <jkridner> koen: I haven't had a chance to try it myself yet.
  • [14:36:02] <jkridner> koen: I won't. I'm trying to reproduce each of the projects as much as I can.
  • [14:36:12] <jkridner> that's why I wanted to know if anyone has been able to get the u-boot musb gadget working.
  • [14:37:27] * n6pfk (n=mike@c-76-104-54-202.hsd1.va.comcast.net) has joined #beagle
  • [14:43:59] * keesj (n=keesj@ip49-193-210-87.adsl2.static.versatel.nl) Quit (Remote closed the connection)
  • [14:44:13] * maelcum (n=quassel@e178154186.adsl.alicedsl.de) Quit (Read error: 60 (Operation timed out))
  • [14:45:18] <Xenion> *** Warning - bad CRC or NAND, using default environment <- what does this tell me ?
  • [14:45:20] <Xenion> :-/
  • [14:45:43] * sunny (i=3ba113e5@gateway/web/ajax/mibbit.com/x-1ddacde8516d4897) has joined #beagle
  • [14:45:55] <Xenion> thanks to uboot-falsh my BB is back to life .. but it won't use autoboot
  • [14:46:02] <Xenion> is there a way to fix this crc issue
  • [14:46:15] <Crofton|work> Xenion, it is basically harmless
  • [14:46:28] <Xenion> i know, but how can i fix it ;)
  • [14:46:37] <sakoman_> Xenion: saveenv
  • [14:46:55] <Xenion> sakoman, hm i think i've tried ..
  • [14:46:56] <sakoman_> That will write th default environemnt and all will be well
  • [14:48:23] * jonnor (n=jon@ti0016a380-4002.bb.online.no) has joined #beagle
  • [14:48:48] <Xenion> sakoman, thanks looked like it works
  • [14:48:52] <Xenion> sakoman, one other thing
  • [14:49:07] <Xenion> my bootcmd got screwed, how can i re set it to MMC boot ?
  • [14:49:09] <Xenion> setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1' setenv bootcmd 'mmcinit;fatload mmc 0 80300000 uImage;bootm 80300000'
  • [14:49:20] <Xenion> i've found this line in the wiki, but it didn't seem to work
  • [14:49:33] <Xenion> last time i did it, i've modified the line .. but i forgot how
  • [14:50:11] <mru> mmcblk0p2 denotes the second partition on the first mmc card
  • [14:50:26] <sakoman_> Xenion: the default environment you just wrote should do the right thing for you
  • [14:50:33] <mru> the mmcblk0 part is correct for the mmc slot on the beagle
  • [14:50:34] <jkridner> looks like you are missing a semicolon
  • [14:50:43] <Xenion> sakoman, you'r right it's the first one
  • [14:50:53] <jkridner> not sure if that is just a cut and paste thing.
  • [14:50:55] <Xenion> jkridner, i just copy&pasted it
  • [14:50:58] <sakoman_> it tries to autodetect an mmc card and use i if it is bootable,othwise it oots from nand
  • [14:52:00] <jkridner> yeah, best not to tie it to an individual boot choice, but to use the new defaults that scan for boot options.
  • [14:53:18] <jkridner> koen: are you trying out u-boot-flash.bin to see if it fixes the environment override?
  • [14:53:31] * sunny (i=3ba113e5@gateway/web/ajax/mibbit.com/x-1ddacde8516d4897) Quit ("http://www.mibbit.com ajax IRC Client")
  • [14:53:33] * jkridner copies it to an SD card myself.
  • [14:55:14] * jkridner copies the pico-i2c utility as well.
  • [14:59:34] <Xenion> http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat <- boot line formating = fail
  • [14:59:44] <Xenion> it just needed a CR
  • [15:01:15] <koen> jkridner: I will be when I reboot, right now I'm trying to get a ubifs volume on NAND
  • [15:01:55] * maelcum (n=quassel@e178163047.adsl.alicedsl.de) has joined #beagle
  • [15:01:57] <koen> sakoman_: don't forget to fill in http://elinux.org/BeagleBoard/contest :)
  • [15:07:30] * jkridner watches videos on Archerfish website because of http://focus.ti.com/pr/docs/preldetail.tsp?sectionId=594&prelId=sc09005 and isn't quite sure what to feel.
  • [15:07:34] <Xenion> win!
  • [15:07:43] <Xenion> nand was broken, fixed, user happy
  • [15:07:49] * jkridner imagines beagleboards being used to watch people all over the world.
  • [15:07:56] <Crofton|work> Xenion, you can boot from NAND?
  • [15:08:04] <Xenion> and use rndis ! :D
  • [15:08:10] <Xenion> my rndis wasn't working
  • [15:08:16] <Xenion> this was due to some uboot bug
  • [15:08:18] * Leon_Nardella1 (n=leon@200-161-14-111.dsl.telesp.net.br) has joined #beagle
  • [15:08:24] <Xenion> just reflashed new version. now rndis works again
  • [15:08:26] * Leon_Nardella (n=leon@200-161-14-111.dsl.telesp.net.br) Quit (Read error: 104 (Connection reset by peer))
  • [15:08:30] <Xenion> quite a mystery
  • [15:08:35] <Xenion> took me a week to find out
  • [15:08:39] <mru> "analytics-enabled video lifestyle management", rotfl
  • [15:10:46] <mru> I'm not sure I want my lifestyle to be managed by a piece of electronics
  • [15:11:03] <sakoman_> koen: don't worry I'll get my points in shortly (after breakfast)
  • [15:15:26] * jkridner notices that my latest u-boot.bin is buggy regarding reading FAT filesystems.
  • [15:15:45] <jkridner> my mac will read files that u-boot won't.
  • [15:16:30] * garren (n=garren@dsl-243-100-242.telkomadsl.co.za) has joined #beagle
  • [15:17:01] <jkridner> mru: I really don't like the idea of someone driving down the road looking at a video of their house.
  • [15:17:28] <jkridner> I think it is interesting that they *can*, but I'd be happy if this person got a ticket.
  • [15:17:37] <garren> hi all
  • [15:17:44] <jkridner> hi garren.
  • [15:17:55] * emeb (n=ericb@ip72-223-90-212.ph.ph.cox.net) has joined #beagle
  • [15:20:16] <jkridner> another TI pico projector: http://arstechnica.com/journals/linux.ars/2009/01/08/bug-labs-continues-to-expand-its-module-list
  • [15:21:28] <Crofton|work> bug is built with OE :)
  • [15:22:37] <koen> jkridner: did you manage to control your pico?
  • [15:22:42] * pH5 (n=ph5@p5485D104.dip.t-dialin.net) has joined #beagle
  • [15:22:49] * koen bows to pH5
  • [15:23:35] * jkridner got stuck on my u-boot not reading the u-boot-flash.bin file on my SD card that I was going to use to reprogram the flash with.
  • [15:23:35] * koen wishes BUGlabs did a armv7a baseBUG
  • [15:23:57] * jkridner wishes people would tell BUGlabs that as well.
  • [15:24:32] <Crofton|work> heh
  • [15:24:41] <Crofton|work> they are kind of like gumstix with plastic cases
  • [15:25:09] <jkridner> even better, just have them use a gumstix in their plastic cases!
  • [15:26:29] <raster> koen: needed to add pkgconfig too :)
  • [15:26:41] <raster> ok
  • [15:26:43] <raster> compile damn u
  • [15:26:45] <raster> ocompile
  • [15:26:53] <raster> and dont bitch about some nfs permission io error goop
  • [15:27:21] * koen stabs mtd-utils
  • [15:27:24] <koen> ubi stuff is in:
  • [15:27:39] <koen> mkfs.ubifs/ ubi-utils *and* ubi-utils/new-utils
  • [15:27:46] <raster> ok
  • [15:27:47] <raster> sleepies
  • [15:27:52] <raster> will attend to this tomorrow
  • [15:28:05] <raster> nite homies!
  • [15:28:07] <raster> :)
  • [15:31:02] * jkridner just notices the FreeBSD entry on the beagle contest.
  • [15:31:07] <jkridner> goodnight raster.
  • [15:31:57] <maelcum> jkridner: are you aware of the usb simultaneous rx/tx lockup?
  • [15:32:05] <maelcum> imho it's not documented well enough
  • [15:32:29] <jkridner> maelcum: I had heard of it some time back, but never understood the issue.
  • [15:32:43] <jkridner> maelcum: do you understand the issue?
  • [15:32:46] <maelcum> http://git.mansr.com/?p=linux-omap;a=commit;h=2e6aa4efb0e14c51ff0427927b1b38136911fa93
  • [15:33:07] <maelcum> well... i've read the patch and its comments. and i can reproduce the issue.
  • [15:33:22] <pH5> koen: that sounds oddly formal
  • [15:33:23] <pH5> hi
  • [15:33:34] <maelcum> i don't claim to fully understand it. i've never heard of the two dma mechanisms that are involved.
  • [15:34:54] <maelcum> i'm using icecream to distribute compile jobs from the beagle. the checkout resides on an external harddisk. that means that there is network (<- more important) and disk i/o.
  • [15:35:08] <maelcum> then it's a matter of minutes to ~2 hours until usb dies, completely
  • [15:35:15] <koen> ubi0:beagleroot on /mnt/flash type ubifs (rw)
  • [15:35:19] <koen> yay!
  • [15:35:49] <jkridner> maelcum: have you tried with this patch? are you looking for more support in getting this patch into linux-omap?
  • [15:36:26] <jkridner> koen: great.
  • [15:36:52] <maelcum> jkridner: if things work fine with the patch i think it is a must-have for linux-omap. in fact it probably is in the pipeline of some maintainer, according to koen (right?).
  • [15:37:28] <maelcum> i've had to apply the patch by hand, but it uses (now) nonexistent functions. i'm currently researching the issue.
  • [15:37:36] <adj_> maelcum: i have also reproduced that issue with my webcam when streaming the output to web browser
  • [15:37:53] <jkridner> maelcum: that doesn't sound like the sort of thing I'd expect koen to keep track of.
  • [15:38:07] <maelcum> it basically makes the board useless for moderate to high i/o loads
  • [15:38:22] <adj_> after applying the patch from Anand usb lock issue is gone but it creates tons of dma misalignment errors
  • [15:38:24] <maelcum> jkridner: he told me about the patch and gave me some pointers
  • [15:38:26] * jkridner notices that he really can't ever *expect* koen to do anything.
  • [15:38:51] <maelcum> adj_: do those errors cause any harm?
  • [15:39:06] <adj_> maelcum: not that i'm aware of
  • [15:39:25] <maelcum> another workaround is to use pio instead of dma. i don't know how much of a slowdown that causes on this architecture...
  • [15:39:34] <maelcum> on pc hardware the slowdown is huge
  • [15:39:52] <jkridner> maelcum: it looks like the patch uses the system DMA for the PIO.
  • [15:40:10] <jkridner> so, it wouldn't really be using the CPU for the transfer.
  • [15:40:19] <koen> ubi0:beagleroot 223.9M 170.8M 48.2M 78% /mnt/flash
  • [15:40:45] <maelcum> dma for pio? i don't understand... pio how i know it (from x86) involves inb/w and outb/w.
  • [15:41:19] <mru> there is no such thing as in* and out* on arm
  • [15:41:29] <mru> it would be plain ldr/str there
  • [15:41:35] <mru> same concept though
  • [15:42:13] <maelcum> no io bus, i suspected that :)
  • [15:43:08] <maelcum> okay, so it's (a loop with) ldr/str mmapped io instead of the usual "tell me when it's done" dma mechanism
  • [15:44:07] <maelcum> adj_: do you have the patch in a form that applies to 2.6.27-omap?
  • [15:44:24] <maelcum> and does it cause a big slowdown? not that it matters much, i need it...
  • [15:45:52] <adj_> i haven't done any serious testing with that patch yet
  • [15:46:15] <maelcum> i, otoh, can't wait to test it :)
  • [15:46:19] <adj_> i think this is the same patch as at the previous link:
  • [15:46:21] <adj_> http://marc.info/?l=linux-omap&m=121861118320951&w=2
  • [15:46:58] <adj_> that patch applies ok, but the first added include line needs to be changed to: <mach/dma.h>
  • [15:47:37] <maelcum> that could very well be the cause of the unknown function calls i get. thanks, i'll try that.
  • [15:47:48] * koen notes that people using OE or angstrom would have that patch applied already
  • [15:48:22] <maelcum> i'm using 2.6.27-oe11 and the patch is not applied
  • [15:48:32] <adj_> koen: are you certain? i've taken my kernel source from oe and that patch was not applied
  • [15:49:53] <Xenion> jkridner, is a micro sd planned for the BB?
  • [15:50:22] <jkridner> not currently. you can easily get to a micro-sd with an adapter.
  • [15:50:23] <maelcum> Xenion: buy an adapter for < $5 ?
  • [15:50:54] <jkridner> the current socket for he BeagleBoard is very flexible to support multiple flash memory types.
  • [15:50:54] <Xenion> jkridner, it's just to save place on the bb platine
  • [15:51:05] <jkridner> platine?
  • [15:51:09] <Xenion> right now every card is based on microsd + adapter
  • [15:51:11] <jkridner> Overo uses microSD.
  • [15:51:16] <Xenion> so why don't use micro sd directly
  • [15:51:26] <Xenion> board
  • [15:51:27] <Xenion> sorry
  • [15:51:28] <koen> adj_: yes, I'm certain
  • [15:51:33] <jkridner> so that SDIO can be used.
  • [15:51:39] <Xenion> jkridner, yes
  • [15:51:49] <koen> for reference: http://dominion.thruhere.net/koen/cms/creating-and-mounting-a-ubifs-volume
  • [15:52:27] <Xenion> jkridner, it's just wasted space :-)
  • [15:52:38] <jkridner> SDIO is wasted space?
  • [15:52:39] <Xenion> nothing "bad" just a feature, would save space and weight
  • [15:52:53] <jkridner> there are bluetooth SDIO cards, for example.
  • [15:53:10] <Xenion> jkridner, if you buy and SD or SDHC card you will get a microSD card wrapped in SD
  • [15:53:15] <Xenion> jkridner, i see
  • [15:53:15] <jkridner> some people like to use the full size SDIO cards for prototyping before making their own boards with SDIO devices soldered down.
  • [15:53:24] <Xenion> jkridner, i see
  • [15:53:38] <maelcum> i like my cheap 8 gigabyet sdhc card. i don't think you can buy cheap 8 gig microsd cards.
  • [15:53:54] <jkridner> small size was not the priority for the current BeagleBoard design.
  • [15:54:02] <Xenion> jkridner, yeah i know
  • [15:54:12] <Xenion> it just came to my mind and i thought i should ask :)
  • [15:54:13] <jkridner> small price for maximum programmer flexibility.
  • [15:54:16] <maelcum> adj_: awesome, changing the include line fixed the build
  • [15:54:29] <jkridner> k. keep the questions coming then!
  • [15:54:42] <Xenion> :-)
  • [15:56:01] <adj_> koen: strange... just about two weeks ago i did fresh OE pull and "bitbake console-image", took the kernel (2.6.27-r5) source
  • [15:56:10] <maelcum> koen: you say you're certain that the rx/tx dma patch is applied in -oe kernels, but i'm pretty sure it's not applied on 2.6.27-oe4 and -oe11. maybe it's applied in 2.6.28-oe<n> ?
  • [15:56:23] <koen> adj_: the kernel is at r12 these days
  • [15:56:32] <adj_> nor can i found the patch in .28-r1 kernel
  • [15:56:33] <koen> maelcum: those are debian kernels, not OE kernels
  • [15:56:55] <maelcum> hm ok, i don't know the difference. sorry.
  • [15:57:25] <adj_> koen: ah, evolution is too fast for me in software development :)
  • [15:57:27] <maelcum> i meant s/oe/oer/ though
  • [15:58:08] <maelcum> i.e. i have tested 2.6.27-oer4 and 11. but yeah, there are debian packages for them, so they are debian kernels.
  • [15:58:21] <maelcum> and i'm using those debian packages
  • [15:59:47] * jkridner notices https://www-a.ti.com/downloads/sds_support/targetcontent/psp/omap35x/index.html
  • [16:00:49] * dcordes (n=dcordes@unaffiliated/dcordes) has joined #beagle
  • [16:01:12] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has left #beagle
  • [16:01:36] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has joined #beagle
  • [16:01:40] <jkridner> "This release package includes a series of patches on top of the 2.6.26
  • [16:01:40] <jkridner> kernel baseline.(including custom patches that will be discontinued)
  • [16:01:40] <jkridner> Based on review and acceptance of these patches in the community,
  • [16:01:40] <jkridner> the current implementation can change in the future. "
  • [16:03:24] * dcordes_ (n=dcordes@unaffiliated/dcordes) Quit (Read error: 60 (Operation timed out))
  • [16:04:58] <koen> jkridner: "custom patches" that replace upstream code with TI code or add to upstream code?
  • [16:05:15] * koen remembers mcbsp patches removing upstream mcbsp code
  • [16:05:23] <jkridner> I haven't looked at the diffs.
  • [16:05:43] <koen> 51 minutes remaining :)
  • [16:06:06] * koen reads releasenotes in the mean time
  • [16:06:13] * jkridner is interested in seeing the "grade" from the community.
  • [16:06:30] * koen grades it 'outdated'
  • [16:06:36] <koen> uboot 1.3.4 and kernel 2.6.26
  • [16:06:44] <koen> that >2 releases behind both
  • [16:07:03] <jkridner> :)
  • [16:07:15] <koen> I have 2.6.28 running on my evm
  • [16:07:23] <koen> with uboot *cough* 1.1.4 *cough*
  • [16:07:43] <jkridner> so this should be a nice upgrade for you. :)
  • [16:07:55] * jkridner notices release notes are dated Nov 28.
  • [16:08:11] <koen> "Future
  • [16:08:12] <koen> releases will migrate to ASoC framework."
  • [16:09:19] <jkridner> :(
  • [16:09:24] <koen> "DVI interface is not supported."
  • [16:09:36] <koen> "Switching back forth between tv and lcd is not supported."
  • [16:10:47] <koen> it seems I only need to apply the v4l2 patch for DSS2 and current 2.6.28 in OE will be better in every way
  • [16:11:40] <koen> jkridner: btw, people keep talking about evm daughterboards (e.g. with TVP5146), is there a webpage about those somewhere?
  • [16:11:54] <koen> jkridner: I can't find them on the mistral site, spectrum digital site or ti.com
  • [16:12:29] <jkridner> not that I know about. I don't think there will be till there is a readily available board.
  • [16:13:01] <koen> :The root filesystem binaries are built using Arago(based on
  • [16:13:05] <koen> OpenEmbedded)"
  • [16:13:07] <koen> nice :)
  • [16:13:10] <jkridner> send me e-mail to remind me to get some info about daugther-card plans posted.
  • [16:13:23] <jkridner> really?
  • [16:13:30] * jkridner feels so out-of-the-loop.
  • [16:13:58] <koen> the release notes say so
  • [16:13:59] * jkridner must have been a pain in too many sides or too distracted with #beagle to be informed/notice.
  • [16:14:50] <jkridner> will be interesting what information is shared on Arago.
  • [16:19:47] <koen> if you know where to look you can checkout all the patches
  • [16:20:05] <koen> not "megapatch", but "patches"
  • [16:26:19] <koen> jkridner: btw, that uboot you linked doesn't work
  • [16:28:41] * jonnor (n=jon@ti0016a380-4002.bb.online.no) has left #beagle
  • [16:29:43] <jkridner> k. odd. source should have been similar to what I gave you before.
  • [16:29:48] <jkridner> symptoms?
  • [16:34:01] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has left #beagle
  • [16:35:23] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has joined #beagle
  • [16:35:43] <koen> xload loads uboot, then nothing
  • [16:36:44] * Crofton|work needs to google arago
  • [16:37:15] <eFfeM> Crofton|work: not much to google for, already did that
  • [16:37:25] <Crofton|work> http://chem.ch.huji.ac.il/history/arago.html
  • [16:38:07] <eFfeM> lol, yes, many arago there but arago and openembedded does not yield much interesting
  • [16:38:54] <koen> it also isn't http://www.arago.utwente.nl/ :)
  • [16:39:36] <eFfeM> lol, no, found that one too
  • [16:41:00] <koen> the EE department shared a 'borrelkelder' with arago
  • [16:41:00] <Crofton|work> try "arago angstrom"
  • [16:41:50] * koen suspects "Dominique Fran??ois Jean Arago"
  • [16:42:32] * Crofton|work agrees
  • [16:42:42] <Crofton|work> there some to be some common research interest
  • [16:43:19] <Crofton|work> jkridner, basically, my feedback is TI needs to better support upstream projects :)
  • [16:43:41] <Crofton|work> I understand the need for some polish for release and "branding"
  • [16:44:23] <Crofton|work> but the problem is that if you aren't pushing upstream hard all the time
  • [16:44:34] <Crofton|work> you get behind, and it gets harder to move stuff upstream
  • [16:44:40] <maelcum> for us free software guys, everything important that is not merged upstream is an annoyance
  • [16:45:38] <Crofton|work> but I think jkridner knows all this already
  • [16:50:15] <Xenion> hello
  • [16:50:52] <Xenion> could there be a simple reason why, RNDIS is working ( the interface is up and correctly configured ) but "ping" isn't working ?
  • [16:52:22] <eFfeM> ping to 127.0.0.1 ?
  • [16:52:27] <jkridner> maelcum: the PSP is intended for folks not ready to work with the instability of code newly going upstream.
  • [16:52:28] <eFfeM> or to another address
  • [16:52:56] <jkridner> the developers are pushing patches against the head of linux-omap, but provide "stable" releases to TI customers.
  • [16:53:34] <Xenion> fixed, forget it .. my host put down usb0 :(
  • [16:53:38] <Xenion> sorry for bothering ..
  • [16:53:43] <jkridner> it takes a while to close the gap between "stable" and "upstream".
  • [16:54:03] <jkridner> I think the team is getting pretty good at pushing patches to linux-omap.
  • [16:54:50] <koen> remember that .26 is a tipping point
  • [16:55:02] <koen> the headermove and twl rewrites come after that
  • [16:55:07] <koen> and DSS2 of course :)
  • [16:56:24] <jkridner> well, dss2 needs to get into linux-omap still.
  • [16:57:03] <jkridner> not having that is making things slow for everybody.
  • [16:57:43] * jkridner isn't aware if tomba needs specific help from TI folks.
  • [16:57:49] <Crofton|work> do you know if "arago" supports cpufreq
  • [16:58:20] <Crofton|work> actually solving the things that rmk go off would be helpful
  • [16:58:28] <koen> Crofton|work: it doesn't
  • [16:58:32] <Crofton|work> heh
  • [16:58:32] <koen> Crofton|work: only cpuidle
  • [16:58:38] <koen> Crofton|work: no smartreflex either
  • [16:58:47] * koen has read the release notese
  • [16:58:52] * Crofton|work hasn't
  • [16:59:02] <Crofton|work> tonight I'll download stuff for plane
  • [16:59:09] <koen> 88.5MB
  • [16:59:16] <Crofton|work> still, it helps our OE credibility
  • [16:59:20] <Crofton|work> rofl
  • [16:59:32] <koen> street cred
  • [16:59:34] <Crofton|work> I wonder if i can get that on the bold?
  • [16:59:35] <koen> aight
  • [16:59:37] <Crofton|work> right
  • [16:59:47] <Crofton|work> when I talk to big shots, I can say, I know OE
  • [17:02:14] * koen stabs cpufreq
  • [17:02:54] * Leon_Nardella1 is now known as Leon_Nardella
  • [17:04:02] * koen notes the PSP has /etc/angstrom-version
  • [17:04:17] * Xerion (i=xerion@82-170-197-160.ip.telfort.nl) Quit (" ")
  • [17:04:20] <Crofton|work> heh
  • [17:04:27] <Crofton|work> don't remind them :)
  • [17:07:42] * CarlMle (i=5604b76c@gateway/web/ajax/mibbit.com/x-880c60e1971fedc1) Quit (Remote closed the connection)
  • [17:07:42] * mib_a9uvhg (i=5cec55b9@gateway/web/ajax/mibbit.com/x-a478b52d043868f4) Quit (Remote closed the connection)
  • [17:19:51] <Xenion> why is it that /sys/devices/system/gpio/gpio0/ is empty ?
  • [17:24:07] * CarlMle (i=5604b76c@gateway/web/ajax/mibbit.com/x-08568bc780a8838a) has joined #beagle
  • [17:27:37] * mib_a9uvhg (i=5cec55b9@gateway/web/ajax/mibbit.com/x-17fa38122ee407d4) has joined #beagle
  • [17:28:45] * eFfeM (n=frans@195-241-226-180.ip.telfort.nl) Quit ("Leaving.")
  • [17:30:08] * CarlMle (i=5604b76c@gateway/web/ajax/mibbit.com/x-08568bc780a8838a) Quit (Remote closed the connection)
  • [17:30:08] * mib_a9uvhg (i=5cec55b9@gateway/web/ajax/mibbit.com/x-17fa38122ee407d4) Quit (Remote closed the connection)
  • [17:31:39] * eFfeM (n=Frans@195-241-226-180.ip.telfort.nl) has joined #beagle
  • [17:33:46] * flo_lap (n=fuchs@g227118180.adsl.alicedsl.de) has joined #beagle
  • [17:33:52] * emeb (n=ericb@ip72-223-90-212.ph.ph.cox.net) Quit ("Leaving.")
  • [17:34:11] * flo_lap is now known as florian
  • [17:36:11] * jsync (n=jess@de3-as6677.alshamil.net.ae) Quit ("Leaving.")
  • [17:37:28] * magnet_ (n=magnet@AMontpellier-259-1-112-182.w90-27.abo.wanadoo.fr) Quit (Read error: 113 (No route to host))
  • [17:45:01] * CarlMle (i=5604b76c@gateway/web/ajax/mibbit.com/x-2fd258f835a76977) has joined #beagle
  • [17:49:56] * keesj (n=keesj@ip49-193-210-87.adsl2.static.versatel.nl) has joined #beagle
  • [17:50:12] * eFfeM (n=Frans@195-241-226-180.ip.telfort.nl) Quit (Read error: 54 (Connection reset by peer))
  • [17:51:59] * eFfeM (n=frans@195-241-226-180.ip.telfort.nl) has joined #beagle
  • [17:52:14] * mib_a9uvhg (i=5cec55b9@gateway/web/ajax/mibbit.com/x-b2b0e5b00a947fb1) has joined #beagle
  • [17:55:11] <koen> Crofton|work: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commitdiff;h=8d28236fb1bccad3d4a3eb7be4a5ffee53589dbe
  • [17:55:50] <koen> - && defined(CONFIG_MACH_OMAP_3430SDP)
  • [17:55:56] <koen> +#elif defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
  • [17:56:00] <koen> sanity!
  • [18:00:04] <Crofton|work> hmm
  • [18:00:10] <Crofton|work> is that in pm-next?
  • [18:00:30] <koen> yes
  • [18:01:19] <Crofton|work> I'm confused
  • [18:03:15] <koen> 100%[====================================>] 2,556,572 9.82M/s
  • [18:03:22] <koen> EHCI helps usb-ethernet :)
  • [18:04:09] <Crofton|work> have you been able to build a kernel that shows p-states?
  • [18:05:08] <tomba> my name has been mentioned!
  • [18:06:11] <tomba> I don't know what you were discussing about, but I am emailing with TI guys about display stuff
  • [18:06:33] <jkridner> tomba: that is what I expect. just making sure.
  • [18:06:42] * Xerion (n=xerion@82-170-197-160.ip.telfort.nl) has joined #beagle
  • [18:06:58] <tomba> they are mainly interested in V4L2, but using my DSS core
  • [18:07:04] <jkridner> tomba: just addressing concerns that it wasn't in TI's EVM kernel release and mentioning that it needs to make it into linux-omap first.
  • [18:07:53] <tomba> well, tony has said he doesn't want it to linux-omap =). he wants the display stuff to go through fbdev-devel and to linus' tree. although I'm not quite sure about the process
  • [18:09:17] <tomba> but there are still a million things to do. although it may never be ready in my opinnion =)
  • [18:19:57] <jkridner> :(
  • [18:39:17] <koen> tomba: what about sending the -test branch for review to fbdev-devel to see what they think of it?
  • [18:43:19] * mib_a9uvhg (i=5cec55b9@gateway/web/ajax/mibbit.com/x-b2b0e5b00a947fb1) Quit ("http://www.mibbit.com ajax IRC Client")
  • [18:54:16] <koen> Crofton|work: http://article.gmane.org/gmane.linux.ports.arm.omap/15496
  • [18:55:11] <Crofton|work> great
  • [18:55:22] <Crofton|work> we'll see what this stirs up
  • [19:06:07] <tomba> koen: that is my plan. just too little time. I was going to send it already this week, but failed
  • [19:06:48] <koen> tomba: I guessed as much when you asked us to test the test branch :)
  • [19:07:19] <koen> hmmm
  • [19:07:25] <koen> those sun spots are interesting
  • [19:07:26] <koen> http://www.sunspotworld.com/products/
  • [19:07:48] <koen> but not ???630 + S&H interesting
  • [19:08:19] * koen wonders if a beagle can do 900 days in deepsleep on a battery
  • [19:08:38] <kulve> sure it can
  • [19:08:43] <kulve> with a BIG battery..
  • [19:08:50] <ds2> koen: why don't you start a test and try it ;)
  • [19:08:51] <koen> I was waiting for somethi
  • [19:08:56] <koen> one to say that :)
  • [19:09:38] <kulve> :)
  • [19:10:44] <ds2> and if it fails, please try again ;)
  • [19:11:43] <mru> but... but... it uses .... java
  • [19:11:45] * mru hides
  • [19:15:25] * lko (n=lko@p5486D970.dip.t-dialin.net) has joined #beagle
  • [19:15:57] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has left #beagle
  • [19:28:27] * gmansi_ (n=gmansi@190.173.83.68) Quit (Read error: 104 (Connection reset by peer))
  • [19:29:51] <lko> hello everyone. i'm trying to get a ShanTou ST268 USB LAN running with beagle board (OpenEmbedded). I know that I need for this a davicom dm9102.c driver. but i cannot find it in that omap kernel tree (there is no drivers/usb/net). Can anyone help ?
  • [19:31:52] * TAK2004 (n=Administ@dslb-088-074-033-214.pools.arcor-ip.net) has joined #beagle
  • [19:33:37] <kulve> lko: there's drivers/net/usb?
  • [19:34:12] <kulve> there's only dm9601.c though..
  • [19:35:11] <kulve> usb/dm9601.c:605: USB_DEVICE(0x0a46, 0x0268), /* ShanTou ST268 USB NIC */
  • [19:37:12] <lko> kulve: no i'm using oe and in tmp/work/beagleboard-angstrom-linux-gnueabi/linux-omap-2.6.27-r5/git/drivers/usb/ is no net
  • [19:37:30] <kulve> cd ..
  • [19:37:31] <kulve> cd net
  • [19:37:32] <kulve> cd usb
  • [19:39:06] <lko> kulve: thanks I'm blind
  • [19:40:09] <kulve> np :)
  • [19:43:34] * __alanc__ (n=a-campbe@nat/ti/x-7d3a638e80fff3b7) has joined #beagle
  • [19:43:41] * pH5 (n=ph5@p5485D104.dip.t-dialin.net) Quit (Read error: 110 (Connection timed out))
  • [19:44:11] * pH5 (n=ph5@p5485BD0C.dip.t-dialin.net) has joined #beagle
  • [19:50:35] * wtd_sicom (i=43a506e5@gateway/web/ajax/mibbit.com/x-cabdb5662a2a13c2) has joined #beagle
  • [19:51:47] * wtd_sicom (i=43a506e5@gateway/web/ajax/mibbit.com/x-cabdb5662a2a13c2) Quit (Client Quit)
  • [19:55:44] * bmxr is still waiting for my USB mini-a cable :(
  • [19:56:27] * magnet_ (n=magnet@AMontpellier-259-1-74-105.w92-133.abo.wanadoo.fr) has joined #beagle
  • [20:04:48] * calculus (n=calculus@gentoo/user/calculus) has joined #beagle
  • [20:07:41] * garren (n=garren@dsl-243-100-242.telkomadsl.co.za) Quit ("Ex-Chat")
  • [20:12:55] * thomasg (n=thomasg@85.131.189.115) Quit (Remote closed the connection)
  • [20:17:58] * thomasg (n=thomasg@85.131.189.115) has joined #beagle
  • [20:19:22] <Crofton|work> so the +5 volt label on the rev A silscreen is wrong, correct?
  • [20:24:48] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has joined #beagle
  • [20:27:22] * florian (n=fuchs@g227118180.adsl.alicedsl.de) Quit (Read error: 113 (No route to host))
  • [20:32:17] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has left #beagle
  • [20:51:35] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has joined #beagle
  • [20:51:58] * JayFoxRox (n=x@a89-183-19-39.net-htp.de) has left #beagle
  • [21:03:41] * aleij (n=ad@183-239.76-83.cust.bluewin.ch) has joined #beagle
  • [21:04:31] * aleij (n=ad@183-239.76-83.cust.bluewin.ch) has left #beagle
  • [21:07:59] * florian (n=fuchs@g227118180.adsl.alicedsl.de) has joined #beagle
  • [21:43:45] * geckosen1tor (n=sean@adsl-68-23-87-156.dsl.dytnoh.ameritech.net) has joined #beagle
  • [21:44:56] <Xenion> Gute Nacht / Good Night - sleep well !! :-)
  • [21:45:11] <Xenion> thxs for the help, everything seems to be workin now :)
  • [21:45:23] * Xenion (n=robert@p579FC1A2.dip.t-dialin.net) Quit ("Verlassend")
  • [21:55:20] * geckosenator (n=sean@ppp-69-218-241-177.dsl.dytnoh.ameritech.net) Quit (Read error: 110 (Connection timed out))
  • [21:55:33] * gregoiregentil (n=zonbu@adsl-71-135-114-242.dsl.pltn13.pacbell.net) has joined #beagle
  • [22:03:19] * pH5 (n=ph5@p5485BD0C.dip.t-dialin.net) Quit ("bye")
  • [22:06:38] * eFfeM (n=frans@195-241-226-180.ip.telfort.nl) has left #beagle
  • [22:19:58] * felipec (n=felipec@a91-153-251-222.elisa-laajakaista.fi) Quit ("Leaving")
  • [22:23:08] * TehUni (n=cory@c-24-30-35-55.hsd1.ga.comcast.net) Quit (Remote closed the connection)
  • [22:36:13] * TehUni (n=cory@c-24-30-35-55.hsd1.ga.comcast.net) has joined #beagle
  • [22:38:42] * zedstar (n=john@fsf/member/zedstar) Quit (Remote closed the connection)
  • [22:39:06] * gregoiregentil (n=zonbu@adsl-71-135-114-242.dsl.pltn13.pacbell.net) has left #beagle
  • [22:40:05] * DJWillis (i=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) Quit ("Manny: It's my scythe. I like to keep it next to where my heart used to be.")
  • [22:51:00] * gregoiregentil (n=zonbu@adsl-71-135-114-242.dsl.pltn13.pacbell.net) has joined #beagle
  • [22:58:11] * valhalla (n=valhalla@81-174-24-85.dynamic.ngi.it) Quit ("Leaving")
  • [23:02:38] * uwe__ (n=uwe_@dslb-084-056-025-225.pools.arcor-ip.net) Quit (Read error: 60 (Operation timed out))
  • [23:06:50] * uwe2 (n=uwe@dslb-084-056-036-221.pools.arcor-ip.net) has joined #beagle
  • [23:16:28] * lko (n=lko@p5486D970.dip.t-dialin.net) Quit ("Leaving.")
  • [23:16:55] * uwe___ (n=uwe@dslb-084-056-025-225.pools.arcor-ip.net) Quit (Read error: 110 (Connection timed out))
  • [23:18:17] * bazbell (n=a0192809@nat/ti/x-dec6a33493f7e5f0) has joined #beagle
  • [23:22:32] * CarlMle (i=5604b76c@gateway/web/ajax/mibbit.com/x-2fd258f835a76977) Quit ("http://www.mibbit.com ajax IRC Client")
  • [23:22:44] * CarlMle2 (i=5604b76c@gateway/web/ajax/mibbit.com/x-5d94847432e584b4) has joined #beagle
  • [23:23:20] * recalcati (i=5d902a55@gateway/web/ajax/mibbit.com/x-24f69f0d14ad89f0) has joined #beagle
  • [23:24:07] <CarlMle2> hi, probably a silly question, I have angstrom running on my beagle, now i want to start running my own code. Do I use a gcc compiler or the code sorcery lite in the faq
  • [23:24:17] <recalcati> I'm trying to create an omapfbplay demo, I compiled it, but I'd like to get all the libraries needed to run the process
  • [23:24:31] * mrc3 (n=ddiaz@189.157.115.100) Quit (Remote closed the connection)
  • [23:24:58] <CarlMle2> by running my own code i dont mean compiling the kernel, just some basic c code to use the serial ports
  • [23:25:30] <recalcati> CarlMle2: Angstrom is compiled with openembedded and so, if you get openembedded for beagleboard you are sure to be compatible
  • [23:27:18] <recalcati> inside Openembedded you'll foind the toolchain
  • [23:29:09] * mib_odkuzs (i=4f1e2a21@gateway/web/ajax/mibbit.com/x-312880794acfb9f3) has joined #beagle
  • [23:29:11] <CarlMle2> yeah openembedded appears to be aimed at creating everything the whole linux image ...
  • [23:29:46] <CarlMle2> i guess im just after the tool chain it uses to compile the applications to run on the omap
  • [23:30:01] <CarlMle2> which i think is code socery?
  • [23:30:27] <recalcati> OE:beagleboard recalcati@recalcati-laptop:~/oe$ ls tmp/cross/armv7a/
  • [23:30:33] <recalcati> arm-angstrom-linux-gnueabi/ bin/ i686-linux/ lib/ libexec/ share/
  • [23:31:15] <recalcati> I found codesourcery in Texas site for compiling the distro for EVM
  • [23:31:33] <recalcati> but I don't know if there are difference from OE toolchain
  • [23:32:25] <recalcati> OE:beagleboard recalcati@recalcati-laptop:~/oe$ ls /home/recalcati/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-gcc --version
  • [23:32:29] <recalcati> ls (GNU coreutils) 6.10
  • [23:33:02] <recalcati> OE:beagleboard recalcati@recalcati-laptop:~/oe$ ./tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi-gcc --version
  • [23:33:07] <recalcati> arm-angstrom-linux-gnueabi-gcc (GCC) 4.3.1
  • [23:33:12] <recalcati> seems different
  • [23:33:28] <recalcati> if you create OE you are sure
  • [23:34:22] * abitos (n=nixgibts@dslb-084-057-155-064.pools.arcor-ip.net) Quit (Read error: 113 (No route to host))
  • [23:40:50] * florian (n=fuchs@g227118180.adsl.alicedsl.de) Quit ("Verlassend")
  • [23:58:46] * uwe__ (n=uwe_@dslb-084-056-036-221.pools.arcor-ip.net) has joined #beagle