• [00:00:17] <mindThomas> Hmm, I just got an image from Narcissus, with all the files
  • [00:00:43] <mindThomas> did you remember to check "Bootloader Files (x-load/u-boot/scripts)" under Platform specific packages?
  • [00:02:36] <xxiao> i used 'advanced' option, did not find any platform on the page?
  • [00:03:45] <xxiao> also there is an omap4430-panda and pandaboard, i used pandaboard though, but don't know the difference
  • [00:04:38] <xxiao> mindThomas: where did you find the platform option?
  • [00:04:42] <xxiao> gosh, it sucks
  • [00:04:56] <xxiao> got it, at the bottom
  • [00:15:28] <mindThomas> yes ;)
  • [00:15:31] <pugvader_>
  • [00:39:24] * rcxking (81a1c212@gateway/web/freenode/ip.129.161.194.18) has joined #beagle
  • [00:39:48] <rcxking> hi, could someone please help with installing ubuntu 10.04 netbook on a beagleboard c4?
  • [00:39:57] <rcxking> I followed the wiki's directions
  • [00:40:14] <rcxking> I'm in the installation screen right now, and I don't know what partitions I need to install ubuntu
  • [00:42:57] <pugvader_> hmm
  • [00:46:42] <rcxking> could someone please help me?
  • [00:57:26] * rcxking (81a1c212@gateway/web/freenode/ip.129.161.194.18) Quit (Quit: Page closed)
  • [00:59:58] <djlewis> i hope he's joking
  • [01:00:45] <mru> djlewis: if not, I'm sure we can remedy that
  • [01:01:00] <djlewis> mru: hi..
  • [01:05:38] <pugvader_> it is a bit depressing to be in an economic depression
  • [01:10:13] * rsalveti (~rsalveti@linaro/rsalveti) Quit (Ping timeout: 240 seconds)
  • [01:13:44] * lyakh (~lyakh@dslb-094-221-108-063.pools.arcor-ip.net) Quit (Quit: Leaving)
  • [01:15:07] * peabody124 (~peabody12@128.249.96.123) Quit (Quit: peabody124)
  • [01:16:01] <xxiao> hmm X11 is not up, console is ok though
  • [01:18:19] <forcedinductionz> Does anyone know of a source tree for u-boot that has a working fastboot implementation?
  • [01:21:17] * coppermine (~inside@unaffiliated/coppermine) has joined #beagle
  • [01:21:26] <coppermine> is the beagle board to be used for skype?
  • [01:21:36] <coppermine> in a robotics application
  • [01:22:11] <xxiao> sigh, still the nfsserver did not work
  • [01:22:41] <xxiao> it seems exportfs works, but can't really mount from another machine, though it can mount a ubuntu one
  • [01:22:51] * mindThomas (~tkjmail@0x4dd5d11f.adsl.cybercity.dk) Quit (Ping timeout: 260 seconds)
  • [01:22:56] <xxiao> i'd like to let ubuntu to mount angstrom's nfsserver back
  • [01:23:07] <xxiao> mount.nfs: access denied by server while mounting 192.168.1.104:/home/nfsroot
  • [01:23:19] <xxiao> sudo mount -t nfs 192.168.1.104:/home/nfsroot /tmp/bb
  • [01:24:32] <coppermine> theoricatelly if i install gentoo on beagleboard xm and then emerge (compile) skype on arm arch it should work?
  • [01:24:36] <coppermine> can osmeone confirm this?
  • [01:25:03] <mru> do you have the skype source code?
  • [01:25:11] <coppermine> mru: its freely available
  • [01:25:14] <coppermine> emerge skype gets it
  • [01:25:17] <coppermine> let me chcek
  • [01:26:05] <coppermine> there's an ebuild for it
  • [01:26:18] <mru> that doesn't mean there's source code
  • [01:26:23] <coppermine> right im still checking
  • [01:26:24] * djerome (~djerome@ip24-251-138-141.ph.ph.cox.net) has joined #beagle
  • [01:26:26] <mru> I highly doubt they released the source
  • [01:26:34] <coppermine> so it wouldnt work
  • [01:26:35] <mru> they've opened a few codecs but that's it
  • [01:26:46] <coppermine> im trying to find an application that would stream me realtime audio/video with the beagleboard
  • [01:26:55] <coppermine> cheese?
  • [01:26:56] <coppermine> kinda sucks
  • [01:29:26] <xxiao> mru: esp M$ now owns it
  • [01:29:45] <coppermine> i see it can be done, watching a youtube video on the beagle streaming video
  • [01:29:56] <coppermine> realtime nice
  • [01:30:23] <xxiao> run a ffmpeg or vlc server?
  • [01:30:29] <coppermine> yeah
  • [01:30:37] <xxiao> you will need hw accel for that for real stuff
  • [01:30:46] <coppermine> beaglebone?
  • [01:31:10] * xxiao spent hours to get nfsserver working on oe, to no avail, sharks
  • [01:32:10] * rsalveti (~rsalveti@186.214.57.24) has joined #beagle
  • [01:32:10] * rsalveti (~rsalveti@186.214.57.24) Quit (Changing host)
  • [01:32:10] * rsalveti (~rsalveti@linaro/rsalveti) has joined #beagle
  • [01:32:17] <coppermine> im reading its slow on the beagleboard for realtime.. this may not be the board i need
  • [01:32:34] <coppermine> mini itx board
  • [01:42:56] <xxiao> on pandaboard angstrom, tcpdump does not run, it needs libnl1, the default is libnl2
  • [01:44:47] * coppermine (~inside@unaffiliated/coppermine) Quit (Quit: Lost terminal)
  • [01:48:24] <mazzanet> i have a c4 running ubuntu maverick
  • [01:48:39] <mazzanet> currently running an old rcn-ee kernel
  • [01:49:10] <mazzanet> when i try the latest ubuntu-ports -omap kernel i lose omapfb and musb
  • [01:49:36] <xxiao> mazzanet: i read somewhere ubuntu is painfully slow, correct?
  • [01:49:49] <xxiao> i mean on arm/beagle/panda
  • [01:50:01] <mazzanet> when i try the latest rcn-ee kernel (both 2.6 and 3.0) everything seems to work but i get extreme packet loss on network interfaces
  • [01:50:20] <mazzanet> xxiao: not really, i've stripped it back bare as much as i can
  • [01:50:26] <mazzanet> running lxde
  • [01:52:42] <mazzanet> and by extreme packet loss i mean 70-80% in ping
  • [01:52:53] <mazzanet> and errors like 'wrong data byte'
  • [02:02:10] * dsoto (~dsoto@pool-74-108-154-167.nycmny.east.verizon.net) Quit (Quit: Computer has gone to sleep)
  • [02:02:34] * dsoto (~dsoto@pool-74-108-154-167.nycmny.east.verizon.net) has joined #beagle
  • [02:07:29] * djerome (~djerome@ip24-251-138-141.ph.ph.cox.net) has left #beagle
  • [02:13:54] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) has joined #beagle
  • [02:26:23] * phantoxe (~destroy@a95-92-89-24.cpe.netcabo.pt) has joined #beagle
  • [02:29:52] * phantone (~destroy@a95-92-89-24.cpe.netcabo.pt) Quit (Ping timeout: 240 seconds)
  • [02:32:57] * peabody124 (~peabody12@c-98-201-161-152.hsd1.tx.comcast.net) has joined #beagle
  • [02:52:27] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) Quit (Quit: slchen)
  • [02:54:17] * A2Sheds (~ly@unaffiliated/l84supper) has joined #beagle
  • [02:54:18] * A2Sheds (~ly@unaffiliated/l84supper) has joined #beaglebone
  • [02:55:14] * peabody124 (~peabody12@c-98-201-161-152.hsd1.tx.comcast.net) Quit (Read error: Connection reset by peer)
  • [02:55:42] * peabody124 (~peabody12@c-98-201-161-152.hsd1.tx.comcast.net) has joined #beagle
  • [02:58:35] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) has joined #beagle
  • [03:03:26] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) has joined #beagle
  • [03:12:16] * dsoto (~dsoto@pool-74-108-154-167.nycmny.east.verizon.net) Quit (Quit: Changing server)
  • [03:25:16] * emeb (~ericb@ip72-223-86-178.ph.ph.cox.net) Quit (Quit: Leaving.)
  • [03:47:56] <xxiao> angstrom trunk is broken for me, back to 2011.03
  • [04:00:52] * thweber (~thomas@ppp-188-174-119-252.dynamic.mnet-online.de) Quit (Ping timeout: 244 seconds)
  • [04:02:38] * thweber (~thomas@host-188-174-132-70.customer.m-online.net) has joined #beagle
  • [04:03:01] * dl9pf (~quassel@p5B2120A1.dip.t-dialin.net) has joined #beagle
  • [04:03:01] * dl9pf (~quassel@p5B2120A1.dip.t-dialin.net) Quit (Changing host)
  • [04:03:01] * dl9pf (~quassel@opensuse/member/dl9pf) has joined #beagle
  • [04:03:49] * dl9pf_ (~quassel@p5B2137DE.dip.t-dialin.net) Quit (Ping timeout: 240 seconds)
  • [04:04:55] * peabody124 (~peabody12@c-98-201-161-152.hsd1.tx.comcast.net) Quit (Quit: peabody124)
  • [04:05:43] * dsoto_af (~dsoto@pool-74-108-154-167.nycmny.east.verizon.net) has joined #beagle
  • [04:14:06] * dsoto_af (~dsoto@pool-74-108-154-167.nycmny.east.verizon.net) has left #beagle
  • [04:19:08] * guanucoluis (~luis@200.127.182.232) has joined #beagleboard
  • [04:26:01] * risca (~risca@f-static-78-70-87-29.business.telia.com) has joined #beagle
  • [04:27:28] * guanucoluis (~luis@200.127.182.232) Quit (Ping timeout: 248 seconds)
  • [04:43:06] * kaio (~kaio@fedora/kaio) Quit (Remote host closed the connection)
  • [04:43:38] * kaio (~kaio@fedora/kaio) has joined #beagle
  • [05:06:16] * kaio (~kaio@fedora/kaio) Quit (Ping timeout: 240 seconds)
  • [05:09:43] * kaio (~kaio@fedora/kaio) has joined #beagle
  • [05:10:06] * gdm_ (~gdm@186.19.75.44) Quit (Ping timeout: 244 seconds)
  • [05:10:47] * gdm_ (~gdm@186.19.75.44) has joined #beagle
  • [05:28:27] * phantoxe (~destroy@a95-92-89-24.cpe.netcabo.pt) Quit ()
  • [05:31:25] * mikey_w (~mike@pool-74-110-218-2.rcmdva.fios.verizon.net) Quit (Remote host closed the connection)
  • [05:31:28] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) Quit (Quit: slchen)
  • [05:55:09] * risca (~risca@f-static-78-70-87-29.business.telia.com) Quit (Ping timeout: 244 seconds)
  • [06:00:22] * risca (~risca@norr-133-129.eduroam.liu.se) has joined #beagle
  • [06:00:23] * leming (~leming@c-75-71-192-135.hsd1.co.comcast.net) Quit (Read error: Connection reset by peer)
  • [06:00:30] * risca (~risca@norr-133-129.eduroam.liu.se) Quit (Remote host closed the connection)
  • [06:04:32] * leming (~leming@c-75-71-192-135.hsd1.co.comcast.net) has joined #beagle
  • [06:07:55] <forcedinductionz> http://i271.photobucket.com/albums/jj141/landcruiserfjz80/kernel/2011-11-19_21-06-27_792.jpg - OMAP3 on ICS
  • [06:19:40] * peabody124 (~peabody12@c-98-201-161-152.hsd1.tx.comcast.net) has joined #beagle
  • [06:46:39] * Russ__ (foobar@ip68-106-254-4.ph.ph.cox.net) has joined #beagle
  • [06:47:47] <_av500_> they ported omap3 to ics
  • [06:48:15] <forcedinductionz> I did a little hacking
  • [06:48:35] <forcedinductionz> software GL at this point, but it's not too bad
  • [06:48:51] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) has joined #beagle
  • [06:50:07] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) Quit (Ping timeout: 258 seconds)
  • [06:56:53] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) has joined #beagle
  • [06:57:15] * Russ__ (foobar@ip68-106-254-4.ph.ph.cox.net) Quit (Read error: Connection reset by peer)
  • [07:04:34] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) Quit (Quit: emeb_mac)
  • [07:18:06] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) Quit (Ping timeout: 258 seconds)
  • [07:18:40] * novogrammer (~novogramm@e0109-49-132-192-17.uqwimax.jp) has joined #beagle
  • [07:19:44] * novogrammer (~novogramm@e0109-49-132-192-17.uqwimax.jp) Quit (Remote host closed the connection)
  • [07:22:05] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) has joined #beagle
  • [07:38:02] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) Quit (Ping timeout: 258 seconds)
  • [07:38:47] * rando303 (~rando@173-25-245-75.client.mchsi.com) Quit (Ping timeout: 245 seconds)
  • [07:39:14] * jay6981 (~Adium@99-90-66-112.lightspeed.sntcca.sbcglobal.net) Quit (Quit: Leaving.)
  • [07:40:41] * mnt_real (~mnt_real@bas1-montreal43-2925254747.dsl.bell.ca) Quit (Quit: Leaving)
  • [07:44:06] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) has joined #beagle
  • [07:51:27] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) Quit (Ping timeout: 258 seconds)
  • [08:02:05] * novogrammer (~novogramm@softbank126108028029.bbtec.net) has joined #beagle
  • [08:04:19] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) has joined #beagle
  • [08:14:23] * chanu (62ef9067@gateway/web/freenode/ip.98.239.144.103) has joined #beagle
  • [08:15:46] * chanu (62ef9067@gateway/web/freenode/ip.98.239.144.103) Quit (Client Quit)
  • [08:16:03] * dENNES (~Adium@188.181.227.245) has joined #beagle
  • [08:17:07] * dm8tbr puts up more port-a-potties
  • [08:18:45] * vpopov (~happylife@dyn-37-70.dzer.fttbee.kis.ru) has joined #beagleboard
  • [08:22:32] <ds2> ?
  • [08:27:52] <ka6sox> very important stuff.
  • [08:28:07] <ds2> :)
  • [08:28:23] <ds2> ka6sox: have I met you in person?
  • [08:30:07] <ka6sox> ELC, SCaLE
  • [08:30:34] <ka6sox> with khem.
  • [08:32:45] <ds2> ah, yes.
  • [08:33:30] * chiques_ (~tony@pool-71-189-111-95.lsanca.fios.verizon.net) has joined #beagle
  • [08:37:48] * perter-jim (~mike@119.123.190.122) Quit (Ping timeout: 244 seconds)
  • [08:47:02] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) Quit (Ping timeout: 258 seconds)
  • [08:52:05] * perter-jim (~mike@183.37.53.252) has joined #beagle
  • [09:01:37] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) has joined #beagle
  • [09:07:34] * Russ__ (foobar@ip68-106-254-4.ph.ph.cox.net) has joined #beagle
  • [09:08:07] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) Quit (Ping timeout: 258 seconds)
  • [09:20:10] * plm (~plm@65.111.170.40) Quit (Quit: Lost terminal)
  • [09:20:30] <ka6sox> flyingbone?
  • [09:20:45] <ka6sox> dang...too used to kthx and thingiverse :p
  • [09:34:05] * vpopov (~happylife@dyn-37-70.dzer.fttbee.kis.ru) Quit (Ping timeout: 252 seconds)
  • [09:36:13] <dm8tbr> ds2: someone ported OMAP3 to ICS...
  • [09:37:05] <unsolo> hmm coppermine .. gstreamer seems to work nicely on my beagle,.
  • [09:50:49] * vpopov (~happylife@dyn-56-47.dzer.fttbee.kis.ru) has joined #beagleboard
  • [09:55:16] * happylife (~happylife@212.92.145.7) Quit (Ping timeout: 258 seconds)
  • [09:59:18] * happylife (~happylife@212.92.145.7) has joined #beagleboard
  • [10:00:29] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) Quit (Quit: Leaving.)
  • [10:18:27] * lyakh (~lyakh@dslb-084-061-106-228.pools.arcor-ip.net) has joined #beagle
  • [10:30:08] * zumbi_ (~zumbi@77.230.237.25) Quit (Ping timeout: 248 seconds)
  • [10:34:02] * Viktator (~victor@95.80.55.37) has joined #beagleboard
  • [10:34:28] * Viktator (~victor@95.80.55.37) has joined #beagle
  • [10:35:58] <Viktator> Im trying to download a Angstrom BeagleBoard demo image from angstrom-distr.org. Is there an alternative source? It is dead slow and it also gets interrupted for me.
  • [10:37:23] <Viktator> Im trying to download a Angstrom BeagleBoard demo image ??? denix
  • [10:37:24] <Viktator> | from angstrom-distr.org. Is there an alternative source? It ??? dENNES
  • [10:37:37] <Viktator> sry for that...
  • [10:38:24] <Viktator> Im trying to download a Angstrom BeagleBoard demo image from angstrom-distr.org. Is there an alternative source? It is dead slow and it also gets interrupted for me.
  • [10:42:54] * xruud (~xruud@541CC56D.cm-5-5d.dynamic.ziggo.nl) has joined #beagleboard
  • [10:45:14] * Alistair (5e0e6a22@gateway/web/freenode/ip.94.14.106.34) has joined #beagle
  • [10:45:36] <Alistair> Good morning guys
  • [10:48:22] <Alistair> I've been studying Kernel drivers to tart to understand Linux more, the documentation I have an can find on the internet tells me that in 2.6 a debate was ongoing regards dropping tasklets in favour of workqueues or some other bottom-half interrupt mechanism but I've been unable to find any documentation relating to the conclusion of this discussion. Does anyone know if a consensus was formed and if there were any kernel changes to g
  • [10:48:28] <Alistair> start*
  • [10:49:09] <koen> Viktator: if you look at that pageit lists mirrors
  • [11:12:57] * mindThomas (~tkjmail@0x4dd5d11f.adsl.cybercity.dk) has joined #beagle
  • [11:18:12] * xruud (~xruud@541CC56D.cm-5-5d.dynamic.ziggo.nl) Quit (Ping timeout: 240 seconds)
  • [11:26:29] * juhsis_ (5f09b131@gateway/web/freenode/ip.95.9.177.49) has joined #beagle
  • [11:28:30] <Viktator> there is a link like: eu.feeds.angstrom etc... but i can't find the file I want i.e. the angstrom beagleboard demo image
  • [11:30:31] <juhsis_> i have a question: i wrote 2 programs; 1 of them works with opencv to open webcam and the other works with gstreamer for same job: open webcam.. In my computer both of them works, but in beagleboard the one with opencv works but with gstreamer does not work.. Do you think why?
  • [11:31:27] <juhsis_> gives "segmentation fault" at this command : g_object_set(G_OBJECT(source), "device", "/dev/video0", NULL);
  • [11:32:21] <juhsis_> btw "/dev/video0" exists in beagleboard..
  • [11:41:20] <Alistair> @juhsis I'm interested to find the result to this as I plan on using gstreamer in an upcoming project
  • [11:41:58] * lyakh (~lyakh@dslb-084-061-106-228.pools.arcor-ip.net) Quit (Quit: Leaving)
  • [11:42:07] <juhsis_> i can help you if you tell me your project
  • [11:42:15] <juhsis_> at least give some hints..
  • [11:44:18] * xruud (~xruud@541CC56D.cm-5-5d.dynamic.ziggo.nl) has joined #beagleboard
  • [11:47:07] <Alistair> @juhsis that would be much appreciated, I have two requirements for video, one is to encode and stream a low-quality feed compatible with a typical HTML5 webbrowser (such as RTP) and the second is to process a higher-quality feed with custom code
  • [11:47:57] <Alistair> Though I'm performing some tasks similar to what can be found in OpenCV, they're very simple and so I'm hoping to avoid its inclusion in the project and use only gstream
  • [11:48:54] <juhsis_> actually opencv is good for iff you want to get image with original quality from webcam..
  • [11:49:33] <juhsis_> the answer of why opencv cant get smaller or bigger size input is : not developed that part yet..
  • [11:50:02] <juhsis_> and gstreamer can do it..
  • [11:50:24] <Alistair> hmmm
  • [11:50:39] <juhsis_> here is the example gstream program : http://gstreamer-devel.966125.n4.nabble.com/appsink-src-example-memory-leak-td971622.html
  • [11:50:48] <Alistair> I think it may all come down to which approach can be done as close to realtime as possible
  • [11:51:03] <Alistair> aha thanks a bunch, I've been looking for such an example
  • [11:51:07] <juhsis_> it uses appsink element to sink image buffer
  • [11:51:23] <juhsis_> i have spent a week for finding that example
  • [11:51:53] <juhsis_> and for playing with sizes and types: for sizes use capabilites
  • [11:51:56] <Alistair> the gstreamer documentation is great I think but there are few finished overall examples
  • [11:52:17] <juhsis_> for types use ffmpegcolorspace
  • [11:53:03] <juhsis_> gstreamer documentation is not includes much example, i think..
  • [11:53:09] <Alistair> ok, for compressed webstream do you recommend a particular video format? It must be widely compatible but also quick to encode as I will be using the beaglebone with no acceleration beyond NEON
  • [11:53:25] <Alistair> bandwidth isn't a big issue
  • [11:54:10] <juhsis_> actually i dont know much about that..
  • [11:54:20] <Alistair> hoho no problem
  • [11:54:37] <Alistair> I'm sure I'll learn a lot more finding out!
  • [11:54:51] <Alistair> I'm just trying to teach myself Drivers at the moment
  • [11:55:00] <juhsis_> i think so, you will need time to learn
  • [11:55:45] <Alistair> yes, a lot to learn, I should not rush so much, it is early days for the BeagleBone
  • [11:57:27] <Alistair> thanks you for the code though, I'll make sure to study it
  • [11:58:00] <juhsis_> your welcome:)
  • [11:58:42] <juhsis_> also http://wiki.oz9aec.net/index.php/Gstreamer_cheat_sheet this can be helpfull
  • [11:59:22] <Alistair> =)
  • [12:05:14] <juhsis_> av500 : why does my beagleboard not open, when i connect it to my PC from otg port only?
  • [12:05:43] <juhsis_> and _av500_ with tails ^^ :)
  • [12:34:21] * W1N9Zr0 (~W1N9Zr0@69-165-245-165.cable.teksavvy.com) Quit (Ping timeout: 258 seconds)
  • [12:48:10] <Alistair> Hmm I see that IRQF_DISABLED is depreciated in Kernel 3.1, what's the now acceptable approach to a fast handler?
  • [13:09:29] <Alistair> ... I see are all IRQs fast now?
  • [13:10:07] * Viktator (~victor@95.80.55.37) Quit (Ping timeout: 248 seconds)
  • [13:12:31] * adj (antti@193.19.136.193) Quit (Ping timeout: 255 seconds)
  • [13:13:01] * adj (antti@hervanta.com) has joined #beagle
  • [13:18:12] * nemik_ (~cyanact@c-67-162-60-211.hsd1.il.comcast.net) has joined #beagle
  • [13:21:25] * nemik (~cyanact@c-67-162-60-211.hsd1.il.comcast.net) Quit (Ping timeout: 240 seconds)
  • [13:24:26] * Viktator (~victor@95.80.55.37) has joined #beagleboard
  • [13:24:26] * Viktator (~victor@95.80.55.37) has joined #beagle
  • [13:36:19] * mranostay (~mranostay@108-64-218-123.lightspeed.moblal.sbcglobal.net) Quit (*.net *.split)
  • [13:36:20] * mdp (~mdp@24.166.64.7) Quit (*.net *.split)
  • [13:36:20] * _av500_ (~av500@lgf.archos.com) Quit (*.net *.split)
  • [13:36:20] * marcheu (~marcheu@annarchy.freedesktop.org) Quit (*.net *.split)
  • [13:36:20] * thuttu77 (~thuttu77@cs181136225.pp.htv.fi) Quit (*.net *.split)
  • [13:36:20] * jevin (~jevin@napalm.jevinskie.com) Quit (*.net *.split)
  • [13:36:23] * andoma (~andoma@zebes.lonelycoder.com) Quit (*.net *.split)
  • [13:36:25] * rafl (rafl@debian/developer/rafl) Quit (*.net *.split)
  • [13:36:27] * mru (~mru@hotblack.mansr.com) Quit (*.net *.split)
  • [13:36:27] * fgau (~fgau@webbox1220.server-home.net) Quit (*.net *.split)
  • [13:36:27] * thuttu77 (~thuttu77@cs181136225.pp.htv.fi) has joined #beagle
  • [13:36:27] * andoma_ (~andoma@zebes.lonelycoder.com) has joined #beagle
  • [13:36:28] * marcheu (~marcheu@annarchy.freedesktop.org) has joined #beagle
  • [13:36:30] * _av500_ (~av500@lgf.archos.com) has joined #beagle
  • [13:36:31] * fgau (~fgau@webbox1220.server-home.net) has joined #beagle
  • [13:36:33] * mranostay (~mranostay@108-64-218-123.lightspeed.moblal.sbcglobal.net) has joined #beagle
  • [13:36:38] * mru (~mru@hotblack.mansr.com) has joined #beagle
  • [13:36:44] * thurbad (~natesewel@cpe-70-124-80-154.austin.res.rr.com) has left #beagle
  • [13:36:53] * mdp (~mdp@cpe-24-166-64-7.neo.res.rr.com) has joined #beagle
  • [13:36:58] * rafl (rafl@goatse.co.uk) has joined #beagle
  • [13:40:21] * jevin (~jevin@napalm.jevinskie.com) has joined #beagle
  • [13:46:52] * phantoxe (~destroy@a95-92-89-24.cpe.netcabo.pt) has joined #beagle
  • [14:08:54] * juhsis_ (5f09b131@gateway/web/freenode/ip.95.9.177.49) Quit (Ping timeout: 265 seconds)
  • [14:11:07] * eephillip (~eephillip@pdpc/supporter/student/eephillip) has joined #beagle
  • [14:11:07] * eephillip (~eephillip@pdpc/supporter/student/eephillip) has joined #beaglebone
  • [14:11:07] * eephillip (~eephillip@pdpc/supporter/student/eephillip) has joined #beagleboard
  • [14:13:49] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) has joined #beagle
  • [14:36:12] * W1N9Zr0 (~W1N9Zr0@69-165-245-165.cable.teksavvy.com) has joined #beagle
  • [14:45:21] * risca (~risca@m77-219-176-148.cust.tele2.se) has joined #beagle
  • [14:49:39] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) Quit (Quit: emeb_mac)
  • [14:50:23] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) has joined #beagle
  • [14:51:04] * vpopov (~happylife@dyn-56-47.dzer.fttbee.kis.ru) Quit (Ping timeout: 240 seconds)
  • [14:54:02] * dsoto_af (~dsoto@pool-74-108-154-167.nycmny.east.verizon.net) has joined #beagle
  • [14:54:49] * dsoto_af (~dsoto@pool-74-108-154-167.nycmny.east.verizon.net) Quit (Client Quit)
  • [15:00:10] * guanucoluis (~luis@200.127.182.232) has joined #beagleboard
  • [15:04:12] * guanucoluis (~luis@200.127.182.232) Quit (Ping timeout: 245 seconds)
  • [15:05:38] <unsolo> Alistair: yes.. and it's been that way for a while..
  • [15:08:25] * novogrammer (~novogramm@softbank126108028029.bbtec.net) Quit (Remote host closed the connection)
  • [15:08:40] <Alistair> @unsolo thanks for the response, are there any exceptions to this behaviour or are all ISRs uninterruptable? Do you know how this plays out from the point of view of the ARM architecture? ie are they all FIQs or all equally ranked IRQs etc?
  • [15:09:16] <mru> that should be covered in the arch ref manual
  • [15:09:23] <mru> make sure you have a copy
  • [15:09:24] <Alistair> @unsolo The issue I've found is that although it has been like this for a while, the latest driver documention floating around in a consolodated form is still based around 2.6.24/26
  • [15:09:45] <mru> rtfs :)
  • [15:10:46] * eephillip (~eephillip@pdpc/supporter/student/eephillip) Quit (Remote host closed the connection)
  • [15:12:54] <Alistair> @mru I have been doing, however source doesn't explain all the intended behaviour without setting off on a journey of discovery and there are few summaries of discussions, which are not well indexed floating around the net, at the end of the day, it's not my intention to become an instant Linux guru and to modify the kernel, I wish to take the role of a user, who may have to implement a driver for a project, it would be counter-produ
  • [15:16:47] * GPSFan (~kenm@64.92.145.112) has joined #beagle
  • [15:17:36] * C-o-r-E (~nash@70.80.16.127) Quit (Ping timeout: 248 seconds)
  • [15:20:12] * guanucoluis (~luis@200.127.182.232) has joined #beagleboard
  • [15:21:10] <Alistair> @mru When you say architecture reference manual, which are you referring to? I have manuals relating to the hardware but do not know where to find one that discusses the use of ARM IRQs by Linux specifically?
  • [15:21:37] <mru> I mean the ARM ARM
  • [15:21:39] <unsolo> Alistair: afaik on the omap one can play with the irq priority
  • [15:22:03] <unsolo> at least among the 96 main irq's
  • [15:22:40] <unsolo> then there are the "power module irq's" the 6 gpio irq bank's etc etc.. to add to that ..
  • [15:23:30] <Alistair> @unsolo I guess my question is, any idea how this ability to play with priority on the architecture level affects the now supposedly uninterruptable linux IRQs? This is what I've been struggling to wrap my head around
  • [15:24:18] <Alistair> ISRs rather
  • [15:24:33] * guanucoluis (~luis@200.127.182.232) Quit (Ping timeout: 258 seconds)
  • [15:25:19] <unsolo> Alistair: something like that can only have an impact on which order they get called in
  • [15:26:23] <unsolo> but im quite sure you should be able to find out more online..
  • [15:26:56] <Alistair> @unsolo I see, so essentially, adjusting ARM IRQ priorities will only have the affect of changing call order or potencially (I suppose) preventing an interrupt from ever reaching linux?
  • [15:27:40] <unsolo> preemption is a topic often handled in SW..
  • [15:27:58] <Alistair> @unsolo If you can point me to a resource I'd be more than happy, I've spent hours back and forth correcting what books and resources have told me against kernel source, changelogs and partial discussions. I've struggled to find a definative source.
  • [15:28:19] <unsolo> if linux irq's are uninterruptable id say all irq context would have to be executed in a non preemtable state.
  • [15:29:01] <Alistair> @unsolo this is what I think too, but I was unsure and did not know where to look to confirm this
  • [15:29:40] <emeb_mac> Alistair: what's your application? Why does it matter?
  • [15:30:29] <unsolo> Alistair: actually the fact that linux irq's are uninterruptable is imho perhaps more a weekness than a strength.
  • [15:30:58] <unsolo> I haven't fiddled with the latest linux kernel so i have no clue as to wha's changed..
  • [15:31:12] <unsolo> +t.
  • [15:31:32] <Alistair> @emeb_mac my application may require custom implementation of PWM (or PRU when more resources are available), I am also trying to learn USB implementation, the main reason right now though, is that to learn effectively, I am documenting the process to teach myself and questions such as this are appearing
  • [15:32:20] <emeb_mac> Alistair: fine - just sounded like your concerns were only valid if you planned to re-write the Linux scheduler
  • [15:33:09] <unsolo> in ticless mode you can greate "iterruptable" offloading in tasklets triggered from your noninterruptable state..
  • [15:33:25] <Alistair> @unsolo from what I gather, the argument was made that interrupts could be accidentally missed if they were made non-premptable, I can't find any concensous but form looking at source it appears it was made anyway, I wonder with perhaps more x86 in mind.
  • [15:33:27] <emeb_mac> from a driver writer's standpoint it seems best to assume that you've got the whole machine. Any context saving is handled by the OS and hardware contention is covered by locks/semaphores, etc.
  • [15:33:28] <unsolo> which will get exectued at the first "free" time the kernel has after that irq..
  • [15:35:00] <Alistair> this is the other thing, it seems tasklets are to be completely replaced with concurrency-managed workqueues else pushed into being softirqs, something else else new thrown into the mix :P
  • [15:35:50] <Alistair> @emed_mac I think you're correct, I must make this assumption, I thought best to check opinion however, as I'm still learning
  • [15:35:50] * mikey_w (~mike@pool-74-110-218-2.rcmdva.fios.verizon.net) has joined #beagle
  • [15:37:27] <unsolo> Alistair: in most cases things work.. if not you use the jiffies counter to figre out if its "time/shcedule" related issues..
  • [15:38:31] <unsolo> Alistair: if its work queues or tasklets doesnt matter the point was.. what happens there is interruptable
  • [15:38:50] * guanucoluis (~luis@200.127.182.232) has joined #beagleboard
  • [15:39:01] <Alistair> @unsolo At 720Mhz it seems unlikely to miss interrupts and i that doesn't happen, 100% no preempting certainly would make life easier. And reg workqueue, gotcha :P
  • [15:39:16] <Alistair> if that*
  • [15:39:38] <unsolo> so if your irq routine just triggers a worker.. (no copying / no work) it will be extremely unlikely to "miss" a irq..
  • [15:39:43] * lyakh (~lyakh@dslb-084-061-106-228.pools.arcor-ip.net) has joined #beagle
  • [15:40:26] <emeb_mac> unsolo: and you hope that all other drivers are written in a similar style. :P
  • [15:41:36] <unsolo> emeb_mac: well thats what the book says right :) any ldd4 coming soon ? hehe
  • [15:41:45] <unsolo> ldd = linux device drivers
  • [15:41:47] <Alistair> @unsolo I think this is why they dropped IRQF_DISABLE, with a robust worker system now in place it makes sense, as you wouldn't want an ISR interrupting if all it was doing was the bare minimum it must, that's no worse that missing the request
  • [15:42:08] <Alistair> no better*
  • [15:43:01] * guanucoluis (~luis@200.127.182.232) Quit (Ping timeout: 240 seconds)
  • [15:43:09] <unsolo> if you have a audio buffer (hw) that has 512 bytes buffered in it and your irq triggers at 256 bytes you have something like 20ms to copy the data out..
  • [15:43:12] <Alistair> :P if ldd is linux device drivers, what's ldd4? :P
  • [15:43:24] <unsolo> so in a lot of cases you have enough time
  • [15:43:36] <unsolo> Alistair: ldd3 is the last revision of it
  • [15:43:39] <unsolo> afaik
  • [15:43:43] <Alistair> a book?
  • [15:43:47] <unsolo> yup
  • [15:43:59] <unsolo> its also online awailable.
  • [15:44:13] <unsolo> but as you are pointing out it's getting old..
  • [15:44:15] <Alistair> Ah yes, the one I purchased was elinuxdd
  • [15:45:17] <Alistair> Well for any interested here's the article on new workqueues from .36 http://lwn.net/Articles/403891/
  • [15:46:37] <Alistair> and IRQF_DISABLED was in the removal schedule http://www.mjmwired.net/kernel/Documentation/feature-removal-schedule.txt#438 (whereas the source just says removed but not why)
  • [15:46:59] <emeb_mac> unsolo: for that paradigm to work best it seems like the default response to an IRQ shouldn't be to call an ISR but to queue up a worker. Make it so the OS owns all ISRs IOW.
  • [15:49:16] <Alistair> I think it's all a fun read, but when I think I have a project to crack on with as well, I wish for more uptodate books :P
  • [15:49:47] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) Quit (Quit: emeb_mac)
  • [15:52:54] * emeb (~ericb@ip72-223-86-178.ph.ph.cox.net) has joined #beagle
  • [15:58:09] * guanucoluis (~luis@200.127.182.232) has joined #beagleboard
  • [16:02:23] * guanucoluis (~luis@200.127.182.232) Quit (Ping timeout: 252 seconds)
  • [16:05:15] * guanucoluis (~luis@200.127.182.232) has joined #beagleboard
  • [16:09:37] * guanucoluis (~luis@200.127.182.232) Quit (Ping timeout: 245 seconds)
  • [16:12:30] * guanucoluis (~luis@200.127.182.232) has joined #beagleboard
  • [16:19:31] * guanucoluis (~luis@200.127.182.232) Quit (Ping timeout: 252 seconds)
  • [16:23:43] * vpopov (~happylife@dyn-56-47.dzer.fttbee.kis.ru) has joined #beagleboard
  • [16:26:36] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) has joined #beagle
  • [16:31:30] * guanucoluis (~luis@200.127.182.232) has joined #beagleboard
  • [16:39:51] * guanucoluis (~luis@200.127.182.232) Quit (Ping timeout: 244 seconds)
  • [16:41:00] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) has joined #beagle
  • [16:43:06] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) Quit (Client Quit)
  • [16:46:55] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) Quit (Quit: slchen)
  • [16:52:50] * eephillip (~eephillip@pdpc/supporter/student/eephillip) has joined #beagle
  • [16:52:50] * eephillip (~eephillip@pdpc/supporter/student/eephillip) has joined #beaglebone
  • [16:52:50] * eephillip (~eephillip@pdpc/supporter/student/eephillip) has joined #beagleboard
  • [16:53:32] * novogrammer (~novogramm@e0109-49-132-192-17.uqwimax.jp) has joined #beagle
  • [16:57:31] * florian (~fuchs@Maemo/community/contributor/florian) has joined #beagle
  • [17:13:21] * dENNES1 (~Adium@188.181.227.245) has joined #beagle
  • [17:13:32] * dENNES (~Adium@188.181.227.245) Quit (Ping timeout: 244 seconds)
  • [17:15:36] * jay6981 (~Adium@99-90-66-112.lightspeed.sntcca.sbcglobal.net) has joined #beagle
  • [17:17:39] * dENNES1 is now known as dENNES
  • [17:26:36] * me345 (~me345@adsl-71-131-134-78.dsl.sntc01.pacbell.net) has joined #beagle
  • [17:32:00] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) has joined #beagle
  • [17:35:19] * thurbad (~natesewel@cpe-70-124-80-154.austin.res.rr.com) has joined #beagle
  • [17:36:39] <unsolo> emeb: well if you have a proper eth controller dma ing the packets to from ram all you need to do is schedule the packet reception and so on..
  • [17:37:43] <emeb> unsolo: indeed - if the hardware is set up right then software timing is a lot less critical.
  • [17:46:17] * chrisw957_home (~chris@ip72-213-155-173.ok.ok.cox.net) Quit (Quit: Ex-Chat)
  • [18:01:06] <unsolo> and there is a reason the omap is packed with dma controllers
  • [18:05:21] <xxiao> anyone here used x11 on panda?
  • [18:05:36] <xxiao> or beagle for that matter, i built an image, booted it from serial, but nothing on lcd
  • [18:07:28] <xxiao> gdm did not start(use xfce)
  • [18:14:12] <mru> someone should make a vt100 driver for X
  • [18:14:35] <emeb> and a 6502 emulator while they're at it.
  • [18:27:31] <xxiao> totally new to the stupid systemd, how do i start nfs server?
  • [18:30:42] * eephillip (~eephillip@pdpc/supporter/student/eephillip) Quit (Remote host closed the connection)
  • [18:31:40] * risca (~risca@m77-219-176-148.cust.tele2.se) Quit (Quit: L??mnar)
  • [18:33:52] * peabody124 (~peabody12@c-98-201-161-152.hsd1.tx.comcast.net) Quit (Read error: Connection reset by peer)
  • [18:33:53] * peabody124_ (~peabody12@c-98-201-161-152.hsd1.tx.comcast.net) has joined #beagle
  • [18:35:49] * xruud (~xruud@541CC56D.cm-5-5d.dynamic.ziggo.nl) Quit (Ping timeout: 240 seconds)
  • [18:36:45] * pugvader (pugvadr@p54866345.dip.t-dialin.net) has joined #beagle
  • [18:40:03] * pugvader_ (~pugvader@p5486745F.dip.t-dialin.net) Quit (Ping timeout: 258 seconds)
  • [18:52:04] * forcedinductionz (~tyler@c-98-225-6-42.hsd1.wa.comcast.net) Quit (Remote host closed the connection)
  • [18:53:45] * prpplague (~prpplague@ppp-70-242-118-38.dsl.rcsntx.swbell.net) has joined #beagle
  • [19:06:47] * pfefferz (~pfefferz@76-205-172-172.lightspeed.austtx.sbcglobal.net) Quit (Quit: Leaving)
  • [19:14:50] * pfefferz (~pfefferz@76-205-172-172.lightspeed.austtx.sbcglobal.net) has joined #beagle
  • [19:21:27] <unsolo> mru: why not a console driver based on the ps3 console
  • [19:21:50] <unsolo> its actually just a matter of asigning a piece of memory to be the "framebuffer" then have the console use that memory area..
  • [19:22:12] <unsolo> and the ofc last piece of that puzzle is to do a blitt of that memory area onto the monitor area..
  • [19:22:19] <mru> there already is a framebuffer driver for ps3
  • [19:22:37] <unsolo> mru: what i meant was to reuse that concept on the beagle..
  • [19:22:53] <unsolo> or panda for that matter.
  • [19:23:26] <mru> there are perfectly good framebuffer drivers for omap
  • [19:23:32] <unsolo> i see
  • [19:23:44] <unsolo> so why do you need the vt1000 driver ?
  • [19:23:47] <unsolo> -0
  • [19:24:00] <thurbad> I thought he was joking...
  • [19:24:05] <unsolo> hehe..
  • [19:24:10] <unsolo> that would make more sense
  • [19:24:51] <mru> I was joking
  • [19:25:02] <unsolo> although
  • [19:25:27] <unsolo> Is there a way to get 1080p output on the omap..
  • [19:25:36] <mru> which omap
  • [19:25:36] <mru> ?
  • [19:25:40] <unsolo> 3
  • [19:25:46] <unsolo> 37x ..
  • [19:25:48] <mru> you can get 1080p30 output
  • [19:25:52] <thurbad> 3530 or 3730
  • [19:25:58] <unsolo> ^
  • [19:26:02] <mru> but you won't have much memory bandwidth left to do anything useful
  • [19:26:39] <unsolo> thats to bad
  • [19:28:23] <mru> get an omap4
  • [19:33:22] * ssvb (~ssvb@a88-114-220-213.elisa-laajakaista.fi) Quit (Quit: Leaving)
  • [19:34:20] <unsolo> mru: hehe maybe..
  • [19:34:56] <thurbad> what's the supply look like on omap 4 based boards? and is the omap 4 binary compatible with omap 3?
  • [19:36:09] * thurbad has an almost hardware starved app running on 3530 based boards ~.~
  • [19:36:46] * unsolo has no idea but i still think i will skip omap4..
  • [19:37:27] <mru> thurbad: supply for what?
  • [19:37:35] <mru> for one-off projects there's the panda
  • [19:38:00] <mru> and there are some omap4 SOMs suitable for production
  • [19:38:04] <thurbad> not one off.. but something that can be based on open hardware
  • [19:38:32] <mru> the problem with omap4 is you can't get them in small numbers
  • [19:39:01] <unsolo> that in my opinion is a huge downside.
  • [19:39:04] <thurbad> no way I can sell management on aboard from scratch
  • [19:39:23] <thurbad> what's small? 100's 1000's
  • [19:39:36] <unsolo> sub 40k
  • [19:39:52] <unsolo> at least thats what our suppliers came up with
  • [19:40:01] <mru> sounds about right
  • [19:40:02] <thurbad> ah, that's a decent sized run ~.~
  • [19:40:19] <mru> http://www.phytec.com/products/som/Cortex-A9/phyCORE-OMAP4430.html
  • [19:40:25] <mru> ^^ 5 seconds with google
  • [19:40:30] * peabody124_ is now known as peabody124
  • [19:40:39] <thurbad> why can't you get them in smaller numbers, do they only fire up the plant for large runs :P
  • [19:40:49] <mru> I don't know
  • [19:41:01] <unsolo> <-- belives it has to do with it beeing a non DM/AM
  • [19:41:10] <mru> that's a non-reason
  • [19:41:26] <mru> they could easily slap a different label on the chip if they wanted
  • [19:41:40] <unsolo> but when they do people start ordering 1-2 of them
  • [19:41:49] <thurbad> the 3730 is dm
  • [19:42:02] <thurbad> oops, didn't see the non in there
  • [19:42:17] <mru> yes, for some reason they decided to sell the omap3 in small numbers
  • [19:42:35] <unsolo> My understanding is that the omap3 is the first mobile going into something else.. and TI has yet to do that for omap44xx
  • [19:43:19] <unsolo> the fact that ti also created am33x and all the other "fallouts" from it suggests to me that they may "skip" the A9 in general for non mobile..
  • [19:43:20] <thurbad> we had hard times acquiring more than a few 3530's at a time
  • [19:44:27] <unsolo> which is why im hoping the next series of A15's will come in a dm/am setting..
  • [19:44:42] <mru> time will tell
  • [19:44:56] <mru> but omap5 is still months away
  • [19:45:04] <unsolo> thurbad: took us 5 days to get 15 DM3730's in house
  • [19:45:21] <unsolo> mru: i'm a patient man in the meantime i have a bone to pick :)
  • [19:45:23] <mru> you could probably have had 15k of them in the same time
  • [19:45:46] <unsolo> mru: well what we are going to end up with is 3725's
  • [19:45:50] <thurbad> we're were looking for 1000s
  • [19:45:56] <unsolo> so i guess one would have to wait..
  • [19:46:04] <unsolo> thurbad: dm37's for the win..
  • [19:46:16] <unsolo> but you said you almost depleted them ?
  • [19:46:43] <unsolo> what kind of I/O / app are you running ?
  • [19:46:49] <unsolo> (if you can tell ofc)
  • [19:46:57] <mru> the omap3 is actually a better chip than the omap4 for many applications
  • [19:47:02] <thurbad> not yet, but I'm hoping we'l be getting a higher end processor for the next hardware rev
  • [19:47:29] <xxiao> thurbad: dm816x?
  • [19:47:37] <unsolo> droool
  • [19:47:39] <xxiao> the best A8 from TI in my opinion
  • [19:47:49] <mru> depends on what you need
  • [19:47:51] <unsolo> 1500Mhz ARM + 1200MHZ dsp iirc..
  • [19:48:01] <unsolo> 5W TDP ?
  • [19:48:07] <xxiao> for low-end dm814x is good
  • [19:48:17] <mru> if you need multiple hd video streams, it's a nice chip
  • [19:48:23] <mru> otherwise there are better options
  • [19:48:31] <xxiao> it's super hot now in surveillance
  • [19:48:43] <mru> that's what it was designed for
  • [19:48:48] <unsolo> hehe..
  • [19:49:00] <thurbad> can't really say much more, other than we're driving 720p graphics
  • [19:49:14] <unsolo> thurbad: k.
  • [19:49:22] <mru> dm37xx does 720p just fine
  • [19:49:29] <unsolo> are you running with the 100 series ?
  • [19:49:58] <unsolo> and at 1Ghz
  • [19:50:07] <thurbad> 100 series?
  • [19:50:07] <unsolo> And using the DSP to help out.
  • [19:50:43] <mru> was that question for me?
  • [19:51:12] <unsolo> the dm37xx comes in two series
  • [19:51:29] <mru> it will drive a 720p display without problem
  • [19:51:31] <unsolo> see http://www.ti.com/product/dm3730
  • [19:51:38] <mru> filling it with content is another matter
  • [19:51:43] <thurbad> oh we're using 3530's at the moment
  • [19:51:57] <unsolo> thurbad: ahh the jump up to 37xx is quite high
  • [19:52:23] <thurbad> high in terems of performance difference?
  • [19:52:32] <unsolo> dsp goes from 430Mhz to 800
  • [19:53:06] <unsolo> cpu from 720 to 1000 (provided you where already actually running in opp6)
  • [19:53:12] <thurbad> I've used an xM in some of our prototyping
  • [19:53:13] <xxiao> imx535 is pretty good too, i think it's 1080p60
  • [19:53:19] <xxiao> for decoding, encoding is p30
  • [19:53:31] <mru> xxiao: you're assuming they're doing video codecs
  • [19:53:50] <mru> since they've said nothing, I'm making no such assumption
  • [19:54:02] <xxiao> fsl does not have dsp, but it does have AMD/ATI's hw codec
  • [19:54:13] <unsolo> thurbad: the xm defaults to 800 iirc.. unless you specify mpurate=1000
  • [19:54:16] <mru> fsl?
  • [19:54:20] <xxiao> freescale
  • [19:54:32] <thurbad> and video playback was better.... although since we were targeting 35030, I didn't try increasing quality or resolution
  • [19:54:40] <mru> they have the amd/ati/qualcomm gpu
  • [19:54:43] <thurbad> *3530
  • [19:54:52] <mru> they'll probably move away from that
  • [19:55:06] <mru> you don't want to be buying your gpu from a competitor
  • [19:55:26] <unsolo> hmm i saw somewhere there is a broadcom gpu somewhere as well..
  • [19:55:33] <mru> ok, so you *are* doing video playback
  • [19:55:37] <unsolo> can't put my finger on where..
  • [19:55:46] <thurbad> yeah
  • [19:55:50] <unsolo> thurbad: are you utilizing the DSP ?
  • [19:55:53] <mru> broadcom has all sorts of weird stuff
  • [19:55:59] <thurbad> not at the moment
  • [19:56:11] <unsolo> thurbad: thats is a huge difference..
  • [19:56:20] <xxiao> i think nowadays video stuff are moving towards hw accels
  • [19:56:25] <unsolo> the dsp has more "flops" than the main arm
  • [19:56:30] <xxiao> dsp is mostly for audio and other stuff
  • [19:56:37] <xxiao> floating probably
  • [19:57:00] <mru> unsolo: the dsp has no flops at all, actually
  • [19:57:03] <mru> it's a fixed-point dsp
  • [19:57:10] <unsolo> mru: true
  • [19:57:17] <thurbad> omap without dsp has 0 flops
  • [19:57:19] <unsolo> but its compatible .. in TI world..
  • [19:57:29] <mru> but the peak computation rate is higher than for the arm, yes
  • [19:58:01] <mru> well, maybe
  • [19:58:03] <unsolo> using TI compilers you write the code and run it on 64xx and 67xx anyways
  • [19:58:16] <mru> you can't run float code on a fixed-point dsp
  • [19:58:28] <unsolo> mru: they do a "compat" conversion..
  • [19:58:38] <unsolo> dont make me bring up hackers delight
  • [19:58:58] <unsolo> it will probably not perfom as well.
  • [19:59:00] <mru> maybe they have a way to compile it twice and select which part to use at runtime
  • [19:59:01] <xxiao> is there something called lpddr3?
  • [19:59:19] <unsolo> i have yet to see lpddr2..
  • [19:59:20] <mru> but you simply cannot execute float instructions on a processor that doesn't implement them
  • [19:59:29] <unsolo> mru: i am well aware..
  • [19:59:29] <mru> lpddr2 is on pandaboard
  • [19:59:34] <unsolo> ic
  • [19:59:41] <mru> unsolo: why do you pretend otherwise then?
  • [20:00:02] <unsolo> mru: maybe i should have used the term mips instead of flops-..-
  • [20:00:37] <mru> still pointless numbers
  • [20:00:52] <mru> such figures are always based on peak issue rates
  • [20:00:59] <unsolo> the fact of the matter is that the dsp with its n ALU's and x simd can do more computation than the arm. in a lot of cases.
  • [20:01:01] <mru> which you can never sustain for more than a few cycles anyway
  • [20:01:21] <mru> only if you manage to fill all the slots with something useful
  • [20:01:25] <mru> which you can't in general
  • [20:01:32] <mru> and the arm has neon
  • [20:01:37] <unsolo> indeed
  • [20:01:41] <mru> which is very different from the dsp
  • [20:01:42] <unsolo> the neon is also useful
  • [20:01:52] <mru> but it can do quite a few ops per cycle
  • [20:02:20] <unsolo> iirc doesnt the neon execute in paralell with the main cpu as well ?
  • [20:02:29] <mru> sort of
  • [20:02:41] <mru> the a8 has an instruction fifo between the arm and the neon unit
  • [20:02:44] <unsolo> but the vfp does not execute in paralell with the cpu.
  • [20:02:50] <mru> it does
  • [20:02:54] <unsolo> ah
  • [20:03:16] <unsolo> so theoretically you can do 4 simd operations 1 vfp operation and one general instruction at the same time ?
  • [20:03:30] <mru> 4 simd?
  • [20:03:39] <unsolo> 4 data sets same operation
  • [20:03:47] <mru> where did the 4 come from?
  • [20:04:06] <unsolo> how wide is the neon ?
  • [20:04:11] <unsolo> isnt it 64 bit ?
  • [20:04:14] <mru> depends on instruction
  • [20:04:22] <mru> alu is 128-bit
  • [20:04:28] <mru> multiplier is 64-bit
  • [20:04:56] <unsolo> and do you have short instructions.. for lets say multiply and add 4x16 bit with 4x16 bit ?
  • [20:05:17] <mru> there are multiply-accumulate instructions, yes
  • [20:05:50] <unsolo> and for a float that would mean 2 data sets multiply and accumulate..
  • [20:06:13] <mru> yes, 2 single-precision fp ops per cycle
  • [20:06:38] <unsolo> the 4 is my spu instruction set default..
  • [20:06:50] <mru> now the ARM core can issue 2 instructions per cycle
  • [20:07:08] <unsolo> but can it do that in addition to the vfp ?
  • [20:07:24] <mru> those two can be either arm core instructions or neon/vfp instructions for forwarding to the neon/vfp fifo
  • [20:07:46] <unsolo> i see
  • [20:08:01] <mru> because you can issue instructions to the fifo faster than neon executes them, it's possible to fill the fifo, then run core instructions while it drains
  • [20:08:28] <unsolo> how deep is that fifo ?
  • [20:08:51] * unsolo is curious
  • [20:09:14] <unsolo> although i can probably just read up on it
  • [20:09:48] <mru> I don't think the exact number is in any public documentation
  • [20:10:28] <unsolo> btw what colorspace is the gpu working on ?
  • [20:10:50] <unsolo> since ffmpeg defaults output to yv12/yuv420
  • [20:11:05] <unsolo> im just curious if SW is doing that conversion..
  • [20:11:30] <unsolo> otherwise EZ-Accell maybe a nice help ..
  • [20:11:32] <mru> why would you feed video to the gpu?
  • [20:11:46] <unsolo> actually the framebuffer..
  • [20:12:01] <unsolo> normally the gpu would draw the data to the framebuffer right ..
  • [20:12:02] <mru> the video overlays accept yuv422
  • [20:12:06] <unsolo> <- pc world..
  • [20:12:35] <unsolo> mru: most decoders do output to yuv422..
  • [20:12:43] <mru> no
  • [20:12:47] <unsolo> hmm
  • [20:12:48] <mru> most decoders output yuv420
  • [20:12:54] <unsolo> true..
  • [20:13:16] <unsolo> but 420 -> 422 is quite easy ..
  • [20:13:25] <thurbad> isn't /most/ a subjective word?
  • [20:13:46] <unsolo> <-- remembers mru from ffmpeg he thinks..
  • [20:13:52] <mru> not as easy as you probably think if you want to do it properly
  • [20:14:09] <unsolo> mru: bilinear upscale ?
  • [20:14:10] * me345 (~me345@adsl-71-131-134-78.dsl.sntc01.pacbell.net) Quit (Remote host closed the connection)
  • [20:14:15] <thurbad> or is it definitive in this case
  • [20:14:15] <unsolo> of the u and v
  • [20:14:28] <mru> well, you have to upscale them somehow
  • [20:14:42] <unsolo> i could probably make the DSP do that..
  • [20:14:51] <mru> taking into acount the correct sample locations of both source and destinations
  • [20:14:53] <unsolo> and also do the transfer of the data to the framebuffer..
  • [20:14:58] <mru> they are usually not the same
  • [20:15:13] <unsolo> mru: making that a perfect dsp job ;)
  • [20:15:17] <mru> 420 samples are vertically halfway between y samples
  • [20:15:26] <mru> in 422 they are co-sited
  • [20:15:33] <unsolo> mru: i remeber
  • [20:15:41] <unsolo> i've done all of this in the cell
  • [20:15:58] <unsolo> in a cell.
  • [20:16:36] <unsolo> but seriously would't offloading that to the DSP make lets say the cpu less bothered with that kind of stuff.
  • [20:17:12] * Alistair (5e0e6a22@gateway/web/freenode/ip.94.14.106.34) Quit (Ping timeout: 265 seconds)
  • [20:17:23] <unsolo> or is it so little its not worth it
  • [20:17:44] <unsolo> id bet offloading cabac decoding etc is also an option..
  • [20:17:46] <mru> it eats memory bandwidth regardless
  • [20:17:53] <unsolo> mru: true..
  • [20:18:26] <unsolo> i guess that's what's eventually holding the DM37x back..
  • [20:19:37] <unsolo> so a DM39XX with DDR2 would help xD
  • [20:19:55] <mru> the omap4460 is looking good
  • [20:21:13] <unsolo> haha 12MP stereo camera..
  • [20:21:37] <unsolo> 45nm @1.5GHz
  • [20:23:14] <thurbad> so, what's a reasonable successor to the omap3530, for distribution in the 1k's ? or is that a loaded question?
  • [20:24:05] <unsolo> thurbad: depends on how hw bound you are..
  • [20:24:16] <thurbad> It'd be nice to be able to take a bigger step than the dm3730.. but if that's the answer that's the answer
  • [20:25:19] <unsolo> thurbad: I do not know the answer but the less you "change" things the more likely they are to work
  • [20:25:34] <thurbad> video/audio sync is an issue that keeps biting me in the rear, if it comes out of sync (which it occasionaly does during pausing)
  • [20:26:58] <unsolo> btw regarding the lpddr2 from the omap 5 pages it sais that the omap5432 (the 4 meaning this is a mobile omap.. same as 44xx 34xx and 36xx odd and even) is going to have support for 2xDDR3/DDR3L (which differs from lpddr) in naming i would "asume".
  • [20:27:03] <thurbad> getting rid of SDL would probably help... but haven't had the time to do that yet
  • [20:27:59] <unsolo> thurbad: i ran QT on some omaps using qt-gstreamer but the usb ethenet broke down (traced it to an error of sorts in the usb eth driver)
  • [20:28:16] <unsolo> even used the DSP to RT encode some video..
  • [20:28:45] <unsolo> but i bet ppl in here have more experience than me on that subject.
  • [20:29:18] <thurbad> no ethernet plug here.. although the port is still present technically
  • [20:29:23] <unsolo> Also worth mentioning on the omap5432 it has a 17x17mm BGA and not the 14x14mm POP..
  • [20:29:57] <thurbad> <-- using cus rather than pop currently
  • [20:30:30] <unsolo> cus is nice.
  • [20:31:13] <thurbad> opens up your world in terms of factories that can fabricate boards
  • [20:31:37] <unsolo> anyhow you should take what i meantioned into consideration. if your apps are fairly portable you could be just as happy with a freescale A9..
  • [20:31:53] <thurbad> but it is a pain to ditch the power management ic the beagle uses
  • [20:32:11] <unsolo> <-- still uses that
  • [20:32:15] <unsolo> anyhow..
  • [20:32:19] <unsolo> bbl wife time
  • [20:32:32] <thurbad> so you're still using the fpbga board?
  • [20:32:50] <unsolo> custom.. and not at home..
  • [20:33:11] * Russ__ (foobar@ip68-106-254-4.ph.ph.cox.net) Quit (Remote host closed the connection)
  • [20:33:22] <thurbad> ah, go do the wife time thing :P
  • [20:34:14] <unsolo> haha check this out.. cotton candy from FXI Tech..
  • [20:34:31] <xxiao> that's a good candy, wish i can get one
  • [20:35:02] <unsolo> Developed here in norway it seems
  • [20:36:56] <unsolo> Its in the same city as the Mali is beeing developed so i guess they get their hands on stuff from ARM..
  • [20:37:24] <unsolo> anyhow wife time
  • [20:38:25] * dENNES (~Adium@188.181.227.245) Quit (Quit: Leaving.)
  • [20:40:20] * C-o-r-E (~nash@modemcable127.16-80-70.mc.videotron.ca) has joined #beagle
  • [21:09:39] * cwillu_at_work (~cwillu@cwillu-1-pt.tunnel.tserv13.ash1.ipv6.he.net) Quit (Ping timeout: 244 seconds)
  • [21:10:42] * _roger_ (~a0740758@nat/ti/x-fijrilptjaxsytqk) has joined #beagle
  • [21:10:56] * cwillu_at_work (~cwillu@cwillu-1-pt.tunnel.tserv13.ash1.ipv6.he.net) has joined #beagle
  • [21:15:51] * Viktator (~victor@95.80.55.37) Quit (Ping timeout: 244 seconds)
  • [21:20:20] * bobkatzz (4b574f52@gateway/web/freenode/ip.75.87.79.82) has joined #beagle
  • [21:21:02] <bobkatzz> g'day all
  • [21:22:05] <bobkatzz> well I've sepnt a fine day formatting a new micro SD card and got that all done, got the new Angstrom image and got that loaded on there but my MLO - won't go
  • [21:22:28] <bobkatzz> used dd if of and everything just like the instr but it won't boot
  • [21:23:16] <bobkatzz> of course loaded all the appropriate boot files on after that - so at a loss quite frankly :)
  • [21:23:52] <bobkatzz> BTW I copied the MLO off my other xM card (that came with the BB) any problem with that?
  • [21:24:02] <bobkatzz> _av500_: ping
  • [21:25:12] <bobkatzz> quiet out there ! ;P
  • [21:25:36] <bobkatzz> ok - well - off to try some other scenarios
  • [21:26:21] * bobkatzz (4b574f52@gateway/web/freenode/ip.75.87.79.82) Quit (Quit: Page closed)
  • [21:26:51] <ka6sox> hit ....and run
  • [21:28:42] * Crofton|work (~balister@pool-96-240-172-5.ronkva.east.verizon.net) Quit (Remote host closed the connection)
  • [21:28:49] * Viktator (~victor@95.80.55.37) has joined #beagleboard
  • [21:28:49] * Viktator (~victor@95.80.55.37) has joined #beagle
  • [21:32:53] <_av500_> pong
  • [21:33:34] <_av500_> i guess old MLO
  • [21:33:51] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) has joined #beagle
  • [21:35:51] * Crofton|work (~balister@pool-96-240-172-5.ronkva.east.verizon.net) has joined #beagle
  • [21:45:20] * nemik_ is now known as nemik
  • [21:55:03] * rando303 (~rando@173-25-245-75.client.mchsi.com) has joined #beagle
  • [21:59:32] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) Quit (Quit: emeb_mac)
  • [22:03:07] * novogrammer (~novogramm@e0109-49-132-192-17.uqwimax.jp) Quit (Remote host closed the connection)
  • [22:03:52] * mbucko (~mbucko@host81-155-192-63.range81-155.btcentralplus.com) has joined #beagle
  • [22:13:36] * rcf (~rcf@211.94-243-81.adsl-dyn.isp.belgacom.be) has joined #beagle
  • [22:23:07] * Russ (foobar@ip68-106-254-4.ph.ph.cox.net) has joined #beagle
  • [22:26:00] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) has joined #beagle
  • [22:32:21] * _roger_ (~a0740758@nat/ti/x-fijrilptjaxsytqk) has left #beagle
  • [22:32:25] * emeb_mac (~ericb@ip72-223-86-178.ph.ph.cox.net) Quit (Quit: emeb_mac)
  • [22:35:01] <mindThomas> hi
  • [22:35:55] <mindThomas> Can someone ask me why I can't comile/make Qt using a downloaded SDK from Narcissus? I get the following error: /usr/local/angstrom/arm/libexec/gcc/arm-angstrom-linux-gnueabi/4.4.2/cc1plus: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory
  • [22:35:57] <mindThomas> I am running Ubuntu
  • [22:36:02] <mindThomas> 11.10
  • [22:36:39] * bobkatzz (4b574f52@gateway/web/freenode/ip.75.87.79.82) has joined #beagle
  • [22:37:09] <bobkatzz> _av500_: ping pong - sorry I missed you
  • [22:38:50] <bobkatzz> I saw in the loggs you said "old MLO" ?? it's the one I got off the SD card that came with my xM and it works fine on the original card - just won't work on my newly formatted SD card
  • [22:39:13] <bobkatzz> of course there could be 5001 reasons for that hehe not inclduing the MLO version
  • [22:39:15] * phantone (~destroy@a95-92-89-24.cpe.netcabo.pt) has joined #beagle
  • [22:42:29] <bobkatzz> mru: pioing
  • [22:42:32] * phantoxe (~destroy@a95-92-89-24.cpe.netcabo.pt) Quit (Ping timeout: 245 seconds)
  • [22:45:28] <bobkatzz> ok - off again to seek out solutions
  • [22:45:38] * bobkatzz (4b574f52@gateway/web/freenode/ip.75.87.79.82) Quit (Quit: Page closed)
  • [22:47:29] <unsolo> mindThomas: i had to install qt-dev properly to compile qt apps on angstrom narcissius
  • [22:48:33] <mindThomas> unsolo: and then what about the SDK?
  • [22:48:52] * Viktator (~victor@95.80.55.37) Quit (Quit: WeeChat 0.3.4)
  • [22:57:04] <unsolo> well i just compiled it on target
  • [22:57:45] * phantone (~destroy@a95-92-89-24.cpe.netcabo.pt) Quit ()
  • [22:57:46] <unsolo> but in your case it seems your toolchain is either not properly configured with respect to finding libraries as mpfr is something gcc depends on
  • [22:58:04] <unsolo> so your cross compiler config seems wrong
  • [22:58:39] * phantoxe (~destroy@a95-92-89-24.cpe.netcabo.pt) has joined #beagle
  • [22:59:14] <mindThomas> oh, you compiled the qt apps on the board
  • [22:59:18] <unsolo> yea
  • [22:59:29] <mindThomas> ahh, well yes, that's an opportunity
  • [22:59:31] <mru> btw, I found the a8 neon instruction fifo depth
  • [22:59:38] <unsolo> it's not a microcontroller..
  • [22:59:42] <mru> in a public doc no less
  • [22:59:43] <unsolo> mru: interesting
  • [22:59:43] <mindThomas> I know :P
  • [22:59:50] <mru> 16 is the value
  • [22:59:50] <unsolo> how deep .
  • [22:59:55] <mindThomas> running linux makes everything much more easier
  • [22:59:59] <mindThomas> but also more advanced
  • [23:00:07] <mindThomas> anyways, I think I maybe know my problem
  • [23:00:15] <mindThomas> I am running 64-bit
  • [23:00:26] <mindThomas> that might be a problem, though I have downloaded/selected the SDK as 64-bit
  • [23:00:55] <unsolo> mru: so provided you want to bang as much as possible through the neon it should in a given freq schedule "work" into neon.
  • [23:00:56] <mru> unsolo: http://www.arm.com/files/pdf/A8_Paper.pdf
  • [23:01:16] <unsolo> tnx
  • [23:01:40] <unsolo> mindThomas: something tells me that if you intend to use a x86 SDK to create QT apps.. you may get some issues.
  • [23:01:58] <unsolo> provided the target is non x86
  • [23:03:05] <unsolo> btw if you tell narcissius to create a QT SDK for you and not use the prebuildt QT sdk it should work.. even if it is on a x86_64 (provided it has multilib)
  • [23:03:05] <mindThomas> unsolo: how do you then build on the board
  • [23:03:24] <mindThomas> and yes, I have ticked Native (on target) SDK in narcissus
  • [23:03:34] <mindThomas> I can't use QMAKE
  • [23:03:36] <mru> unsolo: it's usually futile to try doing anything clever with that fifo
  • [23:03:45] <mindThomas> QMAKESPEC has not been set, so configuration cannot be deduced
  • [23:03:50] <unsolo> mru: hehe..
  • [23:04:09] <mru> you have no way of knowing the fill state of it for starters
  • [23:04:22] <unsolo> mindThomas: i was refering to your cross compilling SDK.. you did not specify if its the one created by narcissius or downloaded from QT
  • [23:04:22] <mru> if there are other processes in the system
  • [23:04:46] <mindThomas> it was the one created by narcissus
  • [23:04:55] <unsolo> mru: indeed
  • [23:05:06] <unsolo> it was a theoretical question..
  • [23:06:00] <unsolo> it's kinda like mmx,sse and altivec.. you really have poor control over it. but it's still more efficient than the alternatives..
  • [23:06:28] <unsolo> this was the part i loved on the spu you had full control over it
  • [23:06:30] <mru> this fifo is a peculiarity of the a8
  • [23:06:48] <unsolo> mru: so on the A9 there is none ?
  • [23:07:31] <unsolo> mindThomas: to build on the board .. opkg install qt4-dev or something along those lines.
  • [23:07:34] <unsolo> + qmake ++
  • [23:08:09] <mindThomas> well it is probably already on there
  • [23:08:18] <mru> the a9 microarchitecture is very different
  • [23:08:22] <mindThomas> I am talking about the export definitions
  • [23:08:31] <unsolo> also make sure to run the script to setup QT env variables
  • [23:08:39] * mikey_w (~mike@pool-74-110-218-2.rcmdva.fios.verizon.net) Quit (Remote host closed the connection)
  • [23:08:39] <mindThomas> yes, and where is that?
  • [23:08:48] <unsolo> hmm /usr/share/qt perhaps.
  • [23:08:58] <mindThomas> ahh, nice
  • [23:09:00] <mindThomas> yeah
  • [23:09:01] <unsolo> <-- doesn't remeber of the top of his head.
  • [23:09:23] <unsolo> mru: interesting
  • [23:09:55] <unsolo> so how is A7 A5 and A15 compared to A8 and A9.
  • [23:10:05] <mru> all are different
  • [23:10:34] <unsolo> like waay different or based on each other.
  • [23:11:02] <mru> they are all pipelined :)
  • [23:11:49] <unsolo> meaning A7 A5 and A15 are out of order ?
  • [23:12:05] * emeb (~ericb@ip72-223-86-178.ph.ph.cox.net) has left #beagle
  • [23:12:07] * Viktator (~victor@95.80.55.37) has joined #beagle
  • [23:12:17] * Viktator (~victor@95.80.55.37) has joined #beagleboard
  • [23:12:56] <mru> no
  • [23:13:14] <mru> a9 is somewhat out of order
  • [23:13:25] <mru> a15 is much more out of order
  • [23:13:31] <mru> a5 is in-order
  • [23:13:55] <unsolo> guess A7 is somewhat out of order ?
  • [23:14:31] <mru> there doesn't seem to be a public trm for the a7 yet
  • [23:15:29] <mru> but it's in-order
  • [23:15:32] <mru> which makes sense
  • [23:16:11] <unsolo> why ? less space / cost / power consumption ?
  • [23:16:27] <mru> the a7 is designed as a low-power companion to the a15
  • [23:17:02] <unsolo> mru: i wouldn't be suprised if i saw it do a lot on it's own as well.
  • [23:17:21] <mru> sure, you can build a chip with just an a7 too
  • [23:17:24] <unsolo> what does it lack compared to A8..
  • [23:18:35] <mru> they say it's faster than an a8
  • [23:19:05] <unsolo> It can do Multicore.. which the A8 cannot do.. it has the same core.. it has Neon, VFP LPAE extension(i bet thats a 64 bit addressing scheme) hardware virtualization..
  • [23:19:15] <unsolo> and its > 1GHZ range..
  • [23:19:28] <mru> "same core"?
  • [23:19:42] <unsolo> well it's ARMv7-A
  • [23:19:57] <mru> so same instruction set
  • [23:20:20] <unsolo> tbh i see it as a low cost multicore
  • [23:22:08] <mru> a5 is also mpcore
  • [23:23:05] <unsolo> It doesn't have amba
  • [23:23:36] <unsolo> http://www.arm.com/products/system-ip/amba/amba-open-specifications.php
  • [23:23:37] <mru> sure does
  • [23:24:14] <mru> what about that page?
  • [23:24:17] <unsolo> hmm
  • [23:24:32] <mru> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0433b/CHDIBJFI.html
  • [23:24:57] <unsolo> im not an expert on the subject so i was just wondering if one can replace an core in a AMBA enabled system with another and keep the rest of the IO design
  • [23:25:25] * mindThomas (~tkjmail@0x4dd5d11f.adsl.cybercity.dk) Quit (Ping timeout: 240 seconds)
  • [23:25:30] <mru> there's more to it than the bus connection
  • [23:26:57] <unsolo> indeed. btw its amba4 on a15 and a7 and as far as i can tell the a5 uses amba3 (not sure if it matters at all)
  • [23:27:15] <mru> amba4 has cache coherency extensions
  • [23:27:29] <mru> and probably other enhancements
  • [23:29:19] <unsolo> speculation wise im holding a finger on A7 replacing A8 and A15 becoming the next big thing. hopefully a laptop killer..
  • [23:29:40] <mru> a15 is the high-performance core
  • [23:29:59] <unsolo> <- likes to speculate.. asumption is the mother of all fuckups
  • [23:33:09] <mru> reading the uarch spec for a7 I can't quite see how would be faster than a8 though...
  • [23:33:22] <mru> I guess it can be clocked higher
  • [23:33:36] <unsolo> A8 is already clocked at 1.5 ..
  • [23:34:05] <unsolo> maybe the multicore factor needs to be taken into account
  • [23:34:18] <unsolo> 4 A7's at 1GHZ compared to 1 A8
  • [23:34:28] <mru> that's not a fair or easy comparison
  • [23:35:27] <unsolo> mru: well id guess you would use more w per clk on the 4 but that's just a guess..
  • [23:35:45] <unsolo> and direct clk comparison is indeed not enough
  • [23:36:39] <unsolo> mru: comparing modern processors is rarely easy..
  • [23:36:51] <unsolo> it's not like you can fire up linpack and get a number.
  • [23:36:52] <mru> of course not
  • [23:37:09] <mru> but when comparing cores you should compare the single-thread performance of each
  • [23:37:18] <mru> then take into account any smp capabilities
  • [23:37:25] <mru> both matter
  • [23:37:31] <unsolo> agreed.
  • [23:38:27] <mru> it's probably possible to design an instruction sequence that runs quicker on whichever of a7 and a8 you choose
  • [23:38:46] <mru> but I doubt you can come up with a sequence where any of the others beats the a15
  • [23:38:55] <mru> it's easy to beat an a9 with an a8
  • [23:38:58] <unsolo> mru: i agree on that
  • [23:40:06] <mru> a8 can dual-issue more than a7
  • [23:40:11] <mru> I don't dare go into details
  • [23:40:11] <unsolo> so the A15 will have more processing power/watt than A8 and A7 then provided you tune them to the max and exclude any power saving scheme..
  • [23:40:21] <unsolo> mru: np..
  • [23:41:02] <mru> the a15 has more processing power and uses more electrical power than a7
  • [23:41:20] <mru> I don't know how the perf/power ratios compare
  • [23:41:39] <unsolo> mru: tbh that's whats interesting unless you want to make a cheap ass smartphone.
  • [23:41:53] <mru> but the a15 has lots of transistors
  • [23:42:11] <mru> so even at a low clock you have "a lot" of leakage current
  • [23:42:43] <unsolo> mru: ok follow my thought here.. if the A15 can do more per time frame and use less power doing a "task" than an A7
  • [23:42:58] <mru> I'm not sure it can do it with less power
  • [23:43:06] <mru> probably not actually
  • [23:43:13] <mru> but it does do it faster
  • [23:43:34] <unsolo> mru: in the time frame it does it will it consume more power than the A7
  • [23:44:06] <unsolo> lets take a good example.. encoding a mjpeg2000 frame
  • [23:44:23] <unsolo> if the A15 can process it then sleep inbetween frames
  • [23:44:27] <mru> if the a7 can do it "fast enough", it will use less power
  • [23:44:29] <unsolo> and the A7 can do the same
  • [23:44:51] <unsolo> (im now taking power saving techniques into account) sorry for not mentioning that
  • [23:45:24] <mru> yes, but even with the clock gated, you still have leakage
  • [23:45:31] <unsolo> true.
  • [23:45:34] <mru> and that's a lot more for the a15 than the a7
  • [23:45:44] <unsolo> hmm
  • [23:46:04] <mru> several times more transistors
  • [23:46:20] <unsolo> that does indeed help on the leakage
  • [23:47:05] <mru> so with the a15/a7 pair, the idea is when the a7 is sufficient for what you're doing, you power down the a15 entirely
  • [23:47:09] <mru> thus cut the leakage
  • [23:47:43] <mru> a simpler core uses the power more efficiently but over a longer period of time
  • [23:47:52] <unsolo> guess the reason it's not a5 comes from the above amba incompat..
  • [23:48:09] * dsoto_af (~dsoto@pool-74-108-154-167.nycmny.east.verizon.net) has joined #beagle
  • [23:48:53] <mru> and lpae and virtualisation and etc...
  • [23:49:05] <unsolo> indeed.
  • [23:49:20] <unsolo> guess there is a lot of virtualization going on these days
  • [23:49:32] <unsolo> im still looking for my android with ubuntu..
  • [23:49:45] <mru> it has to have it to work as companion to a15
  • [23:49:59] <unsolo> true..
  • [23:51:02] <unsolo> well i guess the lpae is kinda what makes the A7 go so far beyond A8 and A5 imho.
  • [23:51:28] * mikey_w (~mike@pool-74-110-218-2.rcmdva.fios.verizon.net) has joined #beagle
  • [23:51:32] <unsolo> omap3 stops at 1GB iirc ..
  • [23:51:43] <mru> omap3 yes
  • [23:51:45] <unsolo> rest of the space is reserved for "other" stuff
  • [23:51:51] <mru> other a8 chips run faster
  • [23:51:54] <unsolo> 1GB on the GPMC alone..
  • [23:52:08] <mru> err, /me can't read
  • [23:52:12] <unsolo> <-- is talking memory space.
  • [23:52:23] <mru> but yes, omap3 has max 1GB dram
  • [23:52:46] <unsolo> and the A8 max 8 Gigx..
  • [23:52:49] <mru> the a8 can address a full 4GB of course
  • [23:52:50] <unsolo> -x +s
  • [23:53:19] <unsolo> but it makes sense to have something that scales beyond that.
  • [23:53:23] <mru> in any real system, some of that will necessarily go to mmio stuff
  • [23:54:16] <unsolo> some of it will have to.
  • [23:54:32] * mbucko (~mbucko@host81-155-192-63.range81-155.btcentralplus.com) Quit (Quit: Leaving)
  • [23:55:26] <unsolo> so i forsee a multicore A7 in an DM39xx with DDR3 and more ram..