• [00:35:09] * cian (n=cianh@cian.ws) Quit ()
  • [01:19:18] * Olipro (i=Olipro@unaffiliated/olipro) Quit (Read error: 110 (Connection timed out))
  • [01:52:08] * jkridner|work (n=a0321898@nat/ti/x-c1aa269a39e5d49c) has joined #beagle
  • [01:53:08] * maelcum|id-- (n=maelcum@e178159107.adsl.alicedsl.de) has joined #beagle
  • [01:53:09] * maelcum (n=maelcum@e178145099.adsl.alicedsl.de) Quit (Nick collision from services.)
  • [01:54:10] * jkridner_ is now known as jkridner
  • [01:55:59] * Paulius (n=Paulius@unaffiliated/paulius) Quit ("I'm outta here, bye.")
  • [03:34:51] * shoragan (n=shoragan@debian/developer/shoragan) Quit (Remote closed the connection)
  • [03:36:32] * shoragan (n=shoragan@debian/developer/shoragan) has joined #beagle
  • [03:41:24] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [03:52:06] <jkridner> ah, a quiet evening on #beagle.
  • [03:53:53] * ds2 turns on steam whistles
  • [03:54:55] <ds2> wheeeee my 1.8V to 3.3V converters arrived
  • [03:55:54] <sakoman_> jkridner: I can make some noise if you like!
  • [03:56:16] <jkridner> quiet is good.
  • [03:56:23] * ds2 makes the test tone in the TWL4030 driver output a continous tone }:-)
  • [03:56:46] <jkridner> as long as it doesn't stay that way when someone does decide to speak.
  • [03:56:57] <ds2> =)
  • [03:57:28] <jkridner> continuous tones are good.
  • [03:58:03] <sakoman_> I'll make lots of noise when I finally get onenand working on this board
  • [03:58:12] <ds2> sakoman_: which board?
  • [03:58:32] <sakoman_> a client's OMPA3 board
  • [03:58:38] <sakoman_> OMAP
  • [03:58:42] <sakoman_> can't type!
  • [03:58:48] <ds2> ah
  • [03:59:22] <ds2> I just love how TI likes to alias parts
  • [03:59:35] <sakoman_> doing usb peripheral boots 5000 times a day is making me crazy
  • [03:59:48] <ds2> haha... why are you doing USB boots?
  • [04:00:23] <sakoman_> How else do you breathe life into the board when nand and mmc are broken?
  • [04:00:26] <ds2> I wonder if I'll get a cease and desist letter from TI's lawyers if I put together a web page listing the different aliases for their parts
  • [04:00:31] <ds2> sakoman: serial boot
  • [04:00:40] <ds2> temporary NOR flash
  • [04:01:11] <sakoman_> Tried serial boot, couldn't get it to work
  • [04:01:17] <sakoman_> usb is faster anyway
  • [04:01:41] <ds2> that involves MUSB; must avoid MUSB when possible for sanity purposes
  • [04:01:44] <sakoman_> NOR isn't practical with this board
  • [04:01:58] <sakoman_> nah, it is working flawlessly!
  • [04:02:11] <ds2> there is always JTAG or CSST direct download to ram
  • [04:02:26] <sakoman_> I'm very happy with usb boot. I'll be happy to leave it behind though
  • [04:02:38] <sakoman_> no jtag
  • [04:02:45] <ds2> DOH
  • [04:05:56] * jkridner|work still can't believe no JTAG.
  • [04:06:33] <ds2> jkridner: do you think anyone would care of an part name alias directory was created?
  • [04:06:52] <jkridner|work> don't ask!!!!
  • [04:07:01] <ds2> okay
  • [04:07:21] <jkridner|work> dang it...
  • [04:07:35] <jkridner|work> I would be irresponsible if I didn't say yes.
  • [04:07:41] <jkridner|work> but, many others would not.
  • [04:08:16] <jkridner|work> they aren't aliases in general, they are different product definitions.
  • [04:08:53] <jkridner|work> even if they happen to be the same die, which isn't always guaranteed, they may be tested differently or support may be for different features.
  • [04:09:17] <jkridner|work> it is only when *we* get lazy that we say they are the same part.
  • [04:09:34] <ds2> 'k
  • [04:09:44] <ds2> sorry, didn't mean to irritate you
  • [04:09:56] <jkridner|work> you didn't. :)
  • [04:10:06] <jkridner|work> sorry if it is difficult for me to exit rant mode tonight.
  • [04:10:21] <jkridner|work> export issues have me pounding my head.
  • [04:10:27] <ds2> doh
  • [04:56:14] * maelcum|id-- (n=maelcum@e178159107.adsl.alicedsl.de) Quit (Remote closed the connection)
  • [06:09:09] * methril|away is now known as methril
  • [06:43:17] * trickie|away is now known as trickie
  • [07:13:34] * Beagle1 (n=Beagle1@adsl-215-243-232.kymp.net) has joined #beagle
  • [07:17:28] * trickie (n=trickie@basesoft.xs4all.nl) Quit (brown.freenode.net irc.freenode.net)
  • [07:17:28] * Robot101 (n=robot101@light.bluelinux.co.uk) Quit (brown.freenode.net irc.freenode.net)
  • [07:17:28] * esden`away (n=esden@repl.esden.net) Quit (brown.freenode.net irc.freenode.net)
  • [07:17:28] * shoragan (n=shoragan@debian/developer/shoragan) Quit (brown.freenode.net irc.freenode.net)
  • [07:17:28] * zarquin (n=zarquin@bright-snat.ucc.asn.au) Quit (brown.freenode.net irc.freenode.net)
  • [07:17:28] * k-way (n=keesj@ip49-193-210-87.adsl2.static.versatel.nl) Quit (brown.freenode.net irc.freenode.net)
  • [07:17:28] * koen (n=koen@s55917625.adsl.wanadoo.nl) Quit (brown.freenode.net irc.freenode.net)
  • [07:17:28] * janneg (n=janne@tichy.grunau.be) Quit (brown.freenode.net irc.freenode.net)
  • [07:17:28] * alphaone (n=alphaone@a064.apm.etc.tu-bs.de) Quit (brown.freenode.net irc.freenode.net)
  • [07:17:52] * shoragan (n=shoragan@debian/developer/shoragan) has joined #beagle
  • [07:17:52] * zarquin (n=zarquin@bright-snat.ucc.asn.au) has joined #beagle
  • [07:17:52] * janneg (n=janne@tichy.grunau.be) has joined #beagle
  • [07:17:52] * k-way (n=keesj@ip49-193-210-87.adsl2.static.versatel.nl) has joined #beagle
  • [07:17:52] * koen (n=koen@s55917625.adsl.wanadoo.nl) has joined #beagle
  • [07:17:52] * alphaone (n=alphaone@a064.apm.etc.tu-bs.de) has joined #beagle
  • [07:18:05] * trickie (n=trickie@basesoft.xs4all.nl) has joined #beagle
  • [07:18:05] * Robot101 (n=robot101@light.bluelinux.co.uk) has joined #beagle
  • [07:18:05] * esden`away (n=esden@repl.esden.net) has joined #beagle
  • [07:22:12] <Beagle1> Should it be possible to get devices outside US from D-K or are we having issues...? jkridner?
  • [07:23:45] <koen> good morning all
  • [07:24:16] <Beagle1> ah, GM ;-)
  • [07:44:57] * min_a (n=ubuntu@pd95b4498.dip0.t-ipconnect.de) has joined #beagle
  • [07:46:21] <min_a> good morning
  • [07:46:50] <min_a> I have a question concerning the beagleboard kernel
  • [07:47:51] <mru> morning
  • [07:47:53] <min_a> using the kernel source and the configuration file for the kernel after booting it with the current uboot I am getting random freezes
  • [07:48:23] <min_a> but if I use the provided binary Image of the kernel this doesn't accure
  • [07:49:34] <min_a> first of all I have no idea how to find out what is causing the problem because I am getting no kernel panic output
  • [07:50:29] <koen> whoa
  • [07:50:30] <koen> Timing buffered disk reads: 44 MB in 3.02 seconds = 14.55 MB/sec
  • [07:51:00] <koen> that used to be 5 MiB/s before http://sakoman.net/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=6c4d34031c80ca4b50ffe73a4ef7fe197a760a60
  • [07:56:22] <mru> koen: what produces the LED heartbeat?
  • [07:56:35] <koen> mru: the heartbead led trigger
  • [07:56:40] <koen> s/d/t/
  • [07:56:50] <mru> yes, but what are the internals of that?
  • [07:56:58] <mru> I mean, what does it take to make it stop?
  • [07:57:14] <koen> root@beagleboard:/sys/class/leds# cat beagleboard\:\:led0/trigger
  • [07:57:14] <koen> none nand-disk [mmc0] timer heartbeat
  • [07:57:31] <mru> how dead does the system need to be for the heartbeat to stop?
  • [07:57:55] * koen has now idea
  • [07:58:04] <koen> echo none > /sys/class/leds/beagleboard\:\:led*/trigger makes the heartbeat stop
  • [07:58:14] <mru> of course it does
  • [07:58:44] <koen> remember that the system seemed to have crashed but the DSP video was still decoding?
  • [07:58:54] <mru> yes
  • [07:59:15] <koen> roger said that it was the cpu painted the picture, so a 'crash' might not kill every process
  • [08:20:57] * DJWillis (i=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) Quit (Read error: 110 (Connection timed out))
  • [08:22:23] * RogerMonk (n=a0740758@nat/ti/x-e6e339cf162b18b5) has joined #beagle
  • [08:29:38] * DJWillis (n=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) has joined #beagle
  • [08:45:38] * Olipro (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [08:50:30] * min_a (n=ubuntu@pd95b4498.dip0.t-ipconnect.de) Quit (Read error: 110 (Connection timed out))
  • [08:52:36] * cian (n=cianh@cian.ws) has joined #beagle
  • [08:54:04] * min (n=ubuntu@pd95b4498.dip0.t-ipconnect.de) has joined #beagle
  • [09:23:15] <ldesnogu> stupid questions: I should get my BB next week. Does anyone have reference for a power adapter in Europe (or even better in France...)? Also what SD card and size should I get (I would prefer a speedy one)?
  • [09:24:28] <koen> it should take a 'standard' +5V 500mA positive center plug
  • [09:25:01] <koen> ldesnogu: I use a 4GB sandisk extreme2, it was ???20 and came with its own usb reader
  • [09:25:18] <koen> ldesnogu: mru uses the 8GB version of that (???40, again with reader)
  • [09:25:52] <koen> sorry, ultra2
  • [09:26:09] <ldesnogu> 500 mA? the recommended Digi-Key one (http://beagleboard.org/hardware) is 2A
  • [09:26:42] <koen> it can power from usb, which is only 500mA
  • [09:26:53] <koen> mine powers from atx which is 25A iirc :)
  • [09:27:18] <ldesnogu> hehe I was going to ask if you did not have random crashes due to 500 mA being too low :)
  • [09:27:48] <ldesnogu> what size is the plug? tiny like Nokia phones?
  • [09:28:44] <koen> the Connector (2.1mm I.D. x 5.5mm O.D.)
  • [09:28:48] <koen> according to digikey
  • [09:31:06] <DJWillis> I find the EVM and Pandora do not eat a huge amount of juice most of the time, well under 500mA (I have a 30A big Farnell PSU that is the size of a suitcase, makes them less portable however).
  • [09:31:38] <koen> according to sakoman it's something like 360mA
  • [09:31:51] <ldesnogu> DJWillis: did you try to run 3d demos while C-A8 and DSP and 2d are running at full speed?
  • [09:32:13] <ldesnogu> koen: IIRC sakoman results were at a shell prompt
  • [09:32:51] <ldesnogu> too bad TI did not publish power numbers for OMAP35x yet :)
  • [09:33:04] * bjdooks is looking at one of the swanky electronic psus that have a serial interface and lots of buttons
  • [09:33:11] <DJWillis> ldesnogu: no, it's the .26 kernel for me so no closed stuff to play with.
  • [09:34:28] <koen> ldesnogu: at prompt without power management
  • [09:34:56] <DJWillis> koen: that seems about right, maybe a little high but I am not a Beagle user.
  • [09:35:23] <koen> the beagle has this funky DVI framer chip sucking power
  • [09:35:29] <ldesnogu> koen: if every part of OMAP35x is running things at full speed then power management should not change anything
  • [09:37:42] <DJWillis> koen: very good point. Talking about power you have just reminded me that I really should try that power detection patch for the Triton on the Pandora to toggle the batt charging. One more for the TODO.
  • [09:38:19] <DJWillis> Out of interest do any of you guys find SD's get upset after a while and just refuse to boot the OMAP3's?
  • [09:38:45] <koen> DJWillis: no, the beagleboard other problems tend to pop up first
  • [09:38:58] <koen> DJWillis: I did get 15MB/s read speeds working today :)
  • [09:39:25] * Beagle2 (n=Beagle1@pool-96-252-61-107.bstnma.fios.verizon.net) has joined #beagle
  • [09:40:03] <DJWillis> koen: the 4bit patch, you get much better results then I did (I popped it in my tree a while ago) but then I guess I have crappy cards ;-) - It's such a simple patch with a big win.
  • [09:40:05] <bjdooks> koen: hmm, not bad speed, what card?
  • [09:40:15] * RogerMonk (n=a0740758@nat/ti/x-e6e339cf162b18b5) Quit (Remote closed the connection)
  • [09:40:26] <ldesnogu> koen: SD HC Ultra2 4 GB is rated at 9 MB/s how did you get 15 ?
  • [09:40:38] <ldesnogu> make that 10 MB/s...
  • [09:41:27] <bjdooks> hmm, i should go and pickup an 500 or 750Gb HD to replace the 300Gb /home
  • [09:42:06] <ldesnogu> koen: my bad it looks like there exist several different ultra II, what a mess :-(
  • [09:42:26] <koen> yeah
  • [09:42:46] <ldesnogu> now I have to find a store that has the good one
  • [09:43:15] <DJWillis> koen: are you booting off the SDHC?
  • [09:44:24] <koen> yes
  • [09:48:02] <koen> comparision with nand: http://dominion.thruhere.net/koen/cms/sd-and-nand-read-speeds
  • [09:48:26] <DJWillis> Ahh, for some reason I thought it would only boot off V1 cards (I guess I misunderstood some notes from TI) so I have been scratching around for old 128meg, 256meg etc. etc. - That is really good to know.
  • [09:49:09] <DJWillis> Hmmm, those NAND speeds are pants.
  • [09:50:43] <ldesnogu> koen: does that look like the one you have http://www.materiel.net/ctl/Secure_Digital/38467-SDHC_4_Go_Ultra_II_Plus.html?affcode=clubic
  • [09:50:54] <ldesnogu> it's 40 euros...
  • [09:51:55] * Beagle2 (n=Beagle1@pool-96-252-61-107.bstnma.fios.verizon.net) Quit ()
  • [10:02:10] <ldesnogu> I am lost... the hrm does not explictly says if SDHC is supported
  • [10:11:38] <DJWillis> ldesnogu: some of the OMAP3 EVM stuff specificly states SD V2 is not supported to boot but if Koen says it works I would guess all V2 cards would work as you only need block mode addressing.
  • [10:11:53] <ldesnogu> V2 = sdhc ?
  • [10:12:14] <ldesnogu> anyway I guess that if mru is using a 8 GB then that implies sdhc works
  • [10:12:16] <DJWillis> Yep
  • [10:12:33] <koen> DJWillis: xload and uboot are in NAND on my beagle
  • [10:12:44] <ldesnogu> so it looks like the right one is the sandisk 8 GB Extreme 3
  • [10:13:44] <DJWillis> koen: ahhh, well that may well mean the boot rom is not V2 aware then.
  • [10:15:01] <koen> could someone run hdparm -t /dev/mtdblock3 on the EVM?
  • [10:22:13] <DJWillis> koen: I can tonight if you get no takers
  • [10:25:02] <koen> for an angstrom rootfs it's just a matter of 'opkg install hdparm' :)
  • [10:45:39] * cian (n=cianh@cian.ws) Quit ()
  • [10:51:51] * RogerMonk (n=a0740758@nat/ti/x-715d2e2f87942aa1) has joined #beagle
  • [11:01:31] * RogerMonk (n=a0740758@nat/ti/x-715d2e2f87942aa1) Quit (Remote closed the connection)
  • [11:33:38] <jkridner|work> good morning
  • [11:33:58] <ldesnogu> hi
  • [11:35:32] <Crofton|work> gm
  • [11:38:21] <koen> hey jkridner|work & Crofton|work
  • [11:42:09] * Viral_Sachde (n=Viral_Sa@122.167.150.80) has joined #beagle
  • [11:44:23] * methril is now known as methril|lunch
  • [11:46:37] * RogerMonk (n=a0740758@nat/ti/x-db61601a0b2c9ab8) has joined #beagle
  • [11:54:37] * Viral_Sachde (n=Viral_Sa@122.167.150.80) has left #beagle
  • [11:55:17] <Crofton|work> arg, now the French are buying American wineries
  • [11:55:27] * RogerMonk (n=a0740758@nat/ti/x-db61601a0b2c9ab8) Quit (brown.freenode.net irc.freenode.net)
  • [11:55:27] * Robot101 (n=robot101@light.bluelinux.co.uk) Quit (brown.freenode.net irc.freenode.net)
  • [11:55:27] * trickie (n=trickie@basesoft.xs4all.nl) Quit (brown.freenode.net irc.freenode.net)
  • [11:55:27] * esden`away (n=esden@repl.esden.net) Quit (brown.freenode.net irc.freenode.net)
  • [11:57:30] * RogerMonk (n=a0740758@nat/ti/x-db61601a0b2c9ab8) has joined #beagle
  • [11:57:30] * trickie (n=trickie@basesoft.xs4all.nl) has joined #beagle
  • [11:57:30] * Robot101 (n=robot101@light.bluelinux.co.uk) has joined #beagle
  • [11:57:30] * esden`away (n=esden@repl.esden.net) has joined #beagle
  • [12:17:02] <min> hello
  • [12:18:00] <min> I have the issue that it seems after running the system for some time, that the sd card isn't accessable anymore
  • [12:18:21] <min> has someone experienced something like this ?
  • [12:19:16] * BThompson (n=BThompso@nat/ti/x-e773757009b779a7) has joined #beagle
  • [12:19:30] <Crofton|work> I think I might see this issue
  • [12:19:55] <Crofton|work> which kernel are you using?
  • [12:20:01] <min> 2.6.22.18
  • [12:20:11] <ldesnogu> humph page 64 of HRM_B4 talks about being able to boot from HC-SD
  • [12:20:12] <min> the one from code.google.com
  • [12:20:12] <Crofton|work> hmm
  • [12:20:24] <Crofton|work> I am using the OE kernel
  • [12:20:35] <Crofton|work> 2.6.26 age
  • [12:21:53] <min> were can I get it, I tried the one from the git of monta vista directly but this one had evene more issues
  • [12:23:49] <min> isn't it possible that the sd somehow went to a power state. Isn't to get such information, because I am still able to access the sys and proc filesystem
  • [12:24:12] <min> this lead me to the assumtion that somthing is wrong with the sd card access
  • [12:24:53] <koen> http://www.angstrom-distribution.org/unstable/autobuild/beagleboard/uImage-2.6.26-r48-beagleboard.bin
  • [12:25:29] <Crofton|work> my thoughts exactly
  • [12:25:30] <DJWillis> min: Linux-OMAP GIT with patches from Open Embedded's Beagle recipies seem to be the way forward ;-)
  • [12:26:09] <min> I would be interessted in the corresponding source as well, because I did some adjustments in the display driver
  • [12:27:21] <DJWillis> min: that will have been built with Linux-OMAP git (or Steve's GIT) and the OE patches. koen: is it Steve's or Tony's git out of interest?
  • [12:27:32] <Crofton|work> http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=packages/linux/linux-omap2_git.bb;h=d205131925167662dfdba457b32d94bfdb046b28;hb=3fe310625ada3c9732cfef920e4939d5b87403b4
  • [12:27:55] <Crofton|work> ultimately tony's git
  • [12:28:24] <Crofton|work> Hopefully, Tony gets back from vacation and commits the patch backlog
  • [12:28:27] <min> thank you, will try this one and see ...
  • [12:28:57] <Crofton|work> koen, have you updated the twl series?
  • [12:29:23] <DJWillis> Crofton|work: yep, I seem to have an ever bigger patch pile for each build.
  • [12:30:41] <koen> Crofton|work: yes, it's using v2
  • [12:31:04] <koen> Crofton|work: http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=commitdiff;h=5240360f8e25d0c98ca3e864fa84fa67e085f053
  • [12:31:28] <Crofton|work> great
  • [12:31:57] <Crofton|work> ok, I need to pick through gnu radio and figure out how to add NEON support
  • [12:31:58] * rsalveti (n=salveti@189.70.143.203) Quit (Read error: 110 (Connection timed out))
  • [12:35:16] * methril|lunch is now known as methril
  • [12:39:52] * koen is adding NEON support to mythtv
  • [12:40:26] <koen> basically copying over mru's work into the libs/libavcodec dir
  • [12:43:49] * rsalveti (n=salveti@200.184.118.132) has joined #beagle
  • [12:46:16] <Crofton|work> does mru's work have a dot product routine?
  • [12:50:23] <DJWillis> koen: have you got an TV sticks going with Myth yet or is your focus at the UI end?
  • [12:53:36] * JuanG (n=Juan@nat/ti/x-a575408a1c93f3e1) has joined #beagle
  • [12:55:54] * JuanG (n=Juan@nat/ti/x-a575408a1c93f3e1) has left #beagle
  • [13:09:16] <RogerMonk> koen - have you been able to stream anything from a myth backend yet?
  • [13:27:35] * prpplague (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [14:00:44] <Crofton> http://gnuradio.org/trac/changeset/8976#file0
  • [14:01:22] <Crofton> koen, any thoughts on what the value of cf_with_md_spu is set for beagle/armv7a?
  • [14:02:39] * bazbel1 is now known as bazbell
  • [14:28:04] * RogerMonk (n=a0740758@nat/ti/x-db61601a0b2c9ab8) Quit (Remote closed the connection)
  • [14:45:37] * dirk2 (n=dirk@F3379.f.strato-dslnet.de) has joined #beagle
  • [14:48:48] * RogerMonk (n=a0740758@nat/ti/x-100cbf9b68267a68) has joined #beagle
  • [14:59:03] * BThompson (n=BThompso@nat/ti/x-e773757009b779a7) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [15:04:58] * methril is now known as methril|away
  • [15:22:09] * trickie is now known as trickie|away
  • [15:38:20] * docelic (n=docelic@78.134.199.199) has joined #beagle
  • [15:42:17] * BThompson (n=BThompso@nat/ti/x-43907ea6eea9b597) has joined #beagle
  • [15:55:58] * trickie (n=trickie@a80-101-189-212.adsl.xs4all.nl) has joined #beagle
  • [15:57:20] * Linitrofe_ (n=aaguirre@200-31-112.adsl.terra.cl) has joined #beagle
  • [15:57:52] <Linitrofe_> Hi, All the hardware on the OMAP processor is supported by a vanilla kernel?
  • [15:59:43] <jkridner|work> getting there. most of the people on the IRC are also making use of patches from OpenEmbedded. patches are being pushed to http://source.mvista.com/git to linux-omap-2.6 via Tony Lindgren.
  • [16:00:01] <jkridner|work> btw, that depends on which OMAP...
  • [16:00:08] <jkridner|work> I'm assuming OMAP3530 which is on Beagle.
  • [16:00:23] <jkridner|work> other OMAP devices that have been around a while are fully supported on vanilla kernel.org.
  • [16:01:14] <Linitrofe_> I was thinking of teh PowerVR peripheral
  • [16:01:19] <jkridner|work> also, there are some peripherals that are not targeted for broad market applications and might not be supported.
  • [16:01:41] <jkridner|work> ah. Not yet.
  • [16:03:01] <Linitrofe_> I remember from a long time ago (axim x50v) I started to see long discussions about the powerVR over linux... It will really be supported one day? or it's just a maybe... we hope...
  • [16:03:41] <Linitrofe_> The skull example on the youtube video what kind of acceleration is using?
  • [16:04:24] <jkridner|work> OpenGLES1.1 using PowerVR. Drivers are still closed source, but kernel portions are expected to be opened by the end of this year.
  • [16:05:17] <Linitrofe_> (I'm really exited with the board/OMAP after I saw the youtube video... I have so many questions...)
  • [16:05:21] <jkridner|work> It is committed to provide GPL drivers for the kernel, but they will move proprietary functionality to user-space.
  • [16:07:08] <Linitrofe_> So this drivers taints the kernel and I can't distribute a comercial product using it?
  • [16:07:36] <bjdooks> Linitrofe_: that's something for the lawyers to deal with
  • [16:08:43] <jkridner|work> it is true that today the drivers taint the kernel. You can choose if you'd be comfortable with that or not. our plan is to push hard for the kernel portions to be GPL, but there is non-zero work involved.
  • [16:08:57] <Linitrofe_> hahaha, as I read on the linuxmagazine? poll developers seems to be the ones who deals with this matter (I'm the one struggling at my company to enable linux over our designs )
  • [16:09:29] <Linitrofe_> ok... enough of that
  • [16:10:12] <Linitrofe_> About the beagle board... PoP? Package over Package? Where in this world I can manufacture this kind of boards?
  • [16:11:06] <Linitrofe_> I have many problems just dealing with BGA boards... and the price of teh beagle board? US$150... How you manage that price with such a revolutionary design?
  • [16:11:34] <prpplague> Linitrofe_: backing of TI i suspect
  • [16:11:42] <koen> Crofton: cortex-a8 for MD_CPU
  • [16:11:43] <bjdooks> Linitrofe_: PoP means you don't have to mess about getting huge wiring messes between the cpu and memory
  • [16:11:53] <bjdooks> means savings on the PCB
  • [16:11:58] <bjdooks> and design time
  • [16:12:03] <Linitrofe_> But the manufacture process?
  • [16:12:26] <bjdooks> not sure, we don't have problems with bgas, but then we seem to be able to manufacture stuff that just stump other people...
  • [16:12:38] <prpplague> bjdooks: hehe
  • [16:12:40] <bjdooks> I expect any reasonable BGA handling system will be able to place the memory
  • [16:13:09] <bjdooks> but i'm not a manufacturing type engineer
  • [16:14:42] <jkridner|work> costs were kept low by reducing the number of layers on the board by not pinning out much.
  • [16:15:59] <bjdooks> I keep thinking about trying an layout with Eagle, but i've so many other projects to get on with too...
  • [16:16:08] <Linitrofe_> My very few experience with BGA was a disaster... For my prototypes I didn't find a supplier at the states with good prices... I must send the board to China and it was not very cheap
  • [16:16:40] <jkridner|work> PCB manufacturing is critical to assemble a device with 0.4mm ball pitch.
  • [16:16:43] <bjdooks> Linitrofe_: I work at a company who can design and manufacture, although we get our PCBs jobbed out
  • [16:16:56] <Linitrofe_> 0.4!!! Oh god
  • [16:16:57] <bjdooks> we actually build all our stuff in-house
  • [16:17:07] <jkridner|work> I would not recommend this to others now that TI has plans to offer 0.5mm and 0.65mm ball pitch packages.
  • [16:17:32] <jkridner|work> the 0.65mm ball-pitch package includes "via-channel array", which allows you to use 0.8mm ball-pitch design rules.
  • [16:17:34] <Linitrofe_> bjdooks: Wjere do you work?
  • [16:17:41] <bjdooks> Simtec Electronics
  • [16:18:39] <jkridner|work> the package-on-package assembly is not as tough as 0.4mm ball-pitch, but does require proper handling and controls. There are application notes on the TI website.
  • [16:19:02] <Linitrofe_> Ok... I will check it
  • [16:19:19] <jkridner|work> we've learned that the PCB manufacturing control has a huge impact on the ability to assemble these small ball-pitch devices.
  • [16:19:37] <Linitrofe_> bjdooks: Do you manufacture PCBs 0.4 pitch capable and few units for prototyping?
  • [16:19:55] <jkridner|work> LogicPD provides a system-on-module so that you can let them build the hard part. :)
  • [16:20:18] <Linitrofe_> jkridner|work: Where do you manufacture your PCBs?
  • [16:20:24] <jkridner|work> I suspect others will do something similar as well. That's the direction I'd point people to.
  • [16:20:27] <Linitrofe_> Ok... searching
  • [16:21:05] <jkridner|work> I'll leave that to Gerald on the mailing list to say. I don't like to undermine him by giving away info like that on the IRC channel.
  • [16:21:24] <jkridner|work> I'm sure that if you are serious about getting something built, we can put you in touch with them.
  • [16:21:46] <jkridner|work> i hope you understand we wouldn't want every random person knocking on their door if they aren't serious about doing something.
  • [16:22:16] <jkridner|work> they are a really helpful company that seems quite open.
  • [16:24:03] <Linitrofe_> Oh be sure I'm interested... the OMAP answer exactly all my problems on a new product we are designing but the PCB and assembly process is something we don't resolve yet
  • [16:24:36] <jkridner|work> consider system-on-module.
  • [16:24:48] <jkridner|work> LogicPD or otherwise.
  • [16:25:11] <Linitrofe_> About the beagle board... how do you connect a standard monitor to it? I suspect that the beagle board has a RGB output... At teh video do you use a Analog Devices encoder externally or something like that?
  • [16:26:32] <koen> HDMI
  • [16:26:48] <Linitrofe_> HDMI is the output of the beagle board?
  • [16:26:53] <jkridner|work> DVI-D.
  • [16:27:02] <jkridner|work> over an HDMI connector.
  • [16:27:18] <jkridner|work> TI TFP410.
  • [16:27:32] * cian (n=cian@cian.ws) has joined #beagle
  • [16:27:56] <jkridner|work> schematics are in the hardware reference manual: http://beagleboard.org/hardware
  • [16:29:15] <Linitrofe_> Ok, I'll download them
  • [16:30:01] <cian> jkridner|work: hi, just wondering if you'd had any luck with digikey re. international shipping, I'm considering ordering a board to a colleague in the US and having him forward it to me
  • [16:30:33] <Linitrofe_> So the RAM is connected to the OMAP processor through the PoP and I don't have to waste my time designing the pcb data path to it
  • [16:31:02] <cian> Linitrofe_: Yes, it's pretty sweeet
  • [16:31:07] <Linitrofe_> that's certainly excellent
  • [16:31:16] <Linitrofe_> I'm damn exited
  • [16:31:45] <jkridner|work> not yet and it is looking pretty risky for Monday.
  • [16:32:25] <cian> oh well, distribution is always a pain...
  • [16:36:09] <Linitrofe_> I must make this question: How much do you spend in a prototype unit using BGA technology?
  • [16:38:04] <jkridner|work> I'm not sure who this will offend, but I'd estimate about $10k-$15k for something at the complexity level of Beagle. It is only a matter of time before I get someone really angry at me for sharing things like that.
  • [16:40:01] <koen> $4000 of that figure is for coffee to keep the engineers awake
  • [16:40:19] <Linitrofe_> HAHAHAHAHAHAHAhahahahaha
  • [16:40:23] <Linitrofe_> same here
  • [16:43:08] <jkridner|work> no way that $4000 is enough of a coffee budget.... and I don't even drink the stuff.
  • [16:43:22] <bjdooks> annyoingly, we've a soft-eng who's alergic to coffee, so we can't drink it in the office
  • [16:43:54] <Linitrofe_> what!? and what do you do? water?
  • [16:43:55] <koen> that's why things like mountain dew and jolt exist
  • [16:44:02] <bjdooks> and tea
  • [16:44:19] <Linitrofe_> damn! good tea I hope
  • [16:44:32] <bjdooks> we supply our own to ensure quality tea
  • [16:44:33] <prpplague> jkridner|work: thats a pretty accurate amount for BGA device
  • [16:44:45] * bjdooks is going to take a work break
  • [16:50:30] * gadiyar (n=Smash@122.166.90.101) has joined #beagle
  • [16:56:24] <Linitrofe_> LogicPD looks like a nice place to work
  • [17:11:53] <mru> good morning
  • [17:12:24] * mru arrives back home from work, and sees his name mentioned in the irc log
  • [17:24:59] * johnx (n=john@p4003-ipbf301hodogaya.kanagawa.ocn.ne.jp) Quit (Read error: 110 (Connection timed out))
  • [17:25:50] * johnx (n=john@p2172-ipbf2302hodogaya.kanagawa.ocn.ne.jp) has joined #beagle
  • [17:27:21] * dirk2 (n=dirk@F3379.f.strato-dslnet.de) has left #beagle
  • [17:30:30] <prpplague> Linitrofe_: i don't know about working there, but their boards are terrible, IMHO
  • [17:36:19] * gadiyar (n=Smash@122.166.90.101) has left #beagle
  • [17:39:00] * Beagle5 (n=Beagle5@c-76-31-18-64.hsd1.tx.comcast.net) has joined #beagle
  • [18:05:17] <Linitrofe_> prpplague: thanks for the tip
  • [18:05:35] <Linitrofe_> any suggestions for a good quality board?
  • [18:05:40] <prpplague> Linitrofe_: np, just my opinion
  • [18:05:48] <prpplague> Linitrofe_: with what processor?
  • [18:06:12] <Linitrofe_> any BGA 0.5 0.4 mm (thinking on Altera FPGA and OMAP processors)
  • [18:06:33] <prpplague> sorry, no suggestions on either
  • [18:06:38] <Linitrofe_> ok
  • [18:06:57] * prpplague primarily uses arm920 and arm926 devices
  • [18:08:03] <koen> ah, I think I have a NEON accelerated mythtv now
  • [18:08:18] <koen> well, at least its libavcodec copy supports it
  • [18:08:29] <mru> nice
  • [18:09:04] <Linitrofe_> Any news/information about flash over the OMAP?
  • [18:09:53] <koen> mru: mythtv put in some DVB and osx dvdv stuff, so I couldn't just drop in the ffmpeg tree and tweak config.{h,mak}
  • [18:11:07] <mru> it should be enough to drop in the arm specific files
  • [18:11:15] <mru> I doubt they've been tweaked
  • [18:11:59] <mru> anyhow, this crashing problem is really puzzling
  • [18:12:11] <mru> it doesn't seem related to dispc after all
  • [18:12:26] <koen> I had some trouble with MULH and friends, so I didn't update armv4l/mathops.h
  • [18:12:36] <mru> what kind of trouble?
  • [18:12:55] <mru> those double mpeg audio decoding speed
  • [18:13:33] <koen> something with expecting asm before int64
  • [18:13:49] <mru> huh?
  • [18:13:54] <koen> since this is just a proof of concept I didn't spend to much time on that
  • [18:15:14] <koen> mru: triple your sd speed: http://sakoman.net/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff_plain;h=6c4d34031c80ca4b50ffe73a4ef7fe197a760a60
  • [18:15:31] <mru> I saw that
  • [18:16:31] <koen> you got 7MB out of your sd reader right?
  • [18:17:12] <mru> with the builtin reader in the laptop, yes something like that
  • [18:17:49] * esden`away (n=esden@repl.esden.net) Quit ("Coyote finally caught me")
  • [18:18:48] <koen> I seem to remember that it's possible to crank it up some more by enabling 48MHz mode
  • [18:19:14] <mru> sd read speed isn't a bottleneck for me right now
  • [18:19:24] * walter_ (n=walter@host121.natpool.mwn.de) has joined #beagle
  • [18:19:31] <mru> I'd much rather get this crashing problem solved
  • [18:20:27] <mru> it's actually happening even if I don't touch the framebuffer too
  • [18:20:32] <mru> only not as often
  • [18:21:08] <mru> and I'm at a loss to debug it
  • [18:21:35] <koen> would jtag help?
  • [18:21:42] <mru> don't know
  • [18:21:58] <koen> did you already try running the i2c at 400kHz?
  • [18:22:04] <mru> no
  • [18:22:13] <mru> I don't see any connection there though
  • [18:22:25] * walter_ (n=walter@host121.natpool.mwn.de) Quit (Client Quit)
  • [18:22:29] <mru> and someone said 2.6MHz is supposed to be safe
  • [18:23:37] * nato_havoc (n=walter@host121.natpool.mwn.de) has joined #beagle
  • [18:23:58] <sakoman_> mru: with Paul's patches I haven't had any more i2c issues, even at 2.6Mhz
  • [18:24:08] <mru> I have paul's patches applied
  • [18:24:49] <mru> I've seen one of those "TWL4030 module irq 368 is disabled but can't be masked!" errors even with them
  • [18:24:52] <sakoman_> Without them, only running @ 400Khz would make my machine stable enough to use
  • [18:25:31] <sakoman_> mru: yes, there are still occasional irq glitches! I see one once every couple of days
  • [18:28:49] * paul_pwsan (n=paul@utopia.booyaka.com) has joined #beagle
  • [18:29:18] <koen> speaking of the devil :)
  • [18:29:22] <paul_pwsan> hello everyone
  • [18:29:28] <koen> hey paul_pwsan
  • [18:29:50] <paul_pwsan> can't pretend it was a coincidence, was reading the irc logs...
  • [18:30:25] <paul_pwsan> sakoman_, have you been seeing TWL4030 IRQ messages, or the 'irq -33' messages?
  • [18:30:29] <paul_pwsan> or something else...
  • [18:31:08] <paul_pwsan> koen: you are still seeing the serial console hangs on your beagle, correct?
  • [18:31:11] <sakoman_> paul: I believe that 99% of them have been the deluge of irq -33 message type
  • [18:31:38] <paul_pwsan> sakoman_: yeah same here
  • [18:31:44] <koen> paul_pwsan: yes, I still see them
  • [18:31:52] <koen> paul_pwsan: although they can take >3h to show up
  • [18:33:21] <paul_pwsan> koen: would you be interested in testing out a few patches for that issue? i have some but i am not sure if they work correctly or not, since sometimes reproducing the hang takes a while...
  • [18:34:15] <paul_pwsan> (or anyone else, for that matter)
  • [18:34:43] <koen> I would, but I'm leaving for germany tomorrow morning, so I can't garantee that can test them before tuesday
  • [18:34:51] <paul_pwsan> no guarantees needed :-)
  • [18:35:10] <Crofton> um, but Germany is only a few miles away ....
  • [18:35:29] <koen> Crofton: yes, but I'm headed for berlin :)
  • [18:35:45] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [18:35:45] <Crofton> cool
  • [18:35:59] <jkridner|work> hi Khasim
  • [18:36:02] <Crofton> Going to watch the US presidential campaing?
  • [18:36:02] <sakoman_> paul_pwsan: I plan to push your v2 patches sometime later today, I'd be happy to test the irq -33 patches also.
  • [18:36:25] <khasim> hi jkridner|work
  • [18:36:44] <sakoman_> Been distracted by bringing up a new board and haven't wanted to rock the boat too much.
  • [18:36:45] <paul_pwsan> sakoman_: cool - i don't have patches for the irq -33 thing yet -- suspect that is a dispc problem -- this is for the serial console hang, where sysrq-whatever still works
  • [18:36:50] <koen> Crofton: if he's still in berlin tomorrow, I hope so
  • [18:37:29] <Crofton> you are lucky, you only get a couple of days, we have months of campaigning to go
  • [18:37:32] * Beagle1 (n=Beagle1@adsl-215-243-232.kymp.net) has left #beagle
  • [18:37:49] <sakoman_> paul_pwsan: interestingly I haven't seen the serial hang on this new board (non-beagle, but also uart 3 based)
  • [18:38:09] <paul_pwsan> sakoman_: very interesting
  • [18:39:07] <sakoman_> need more hours with it to say anything definitive, but in one case it was up for a good dozen hours with no serial hang. I've never gone that long on my beagle
  • [18:39:32] <Crofton> I'm trying to mod the gnu radio code for cortex-a8 along the lines of eb's altivec code
  • [18:39:35] <khasim> paul_pwsan: I think the irq 33 problem was fixed on internal release by allocating the IO registers in a different mem region
  • [18:39:39] <paul_pwsan> sakoman_: earlier there was some suspicion that the serial console hang issue was power management-related. but now i suspect it is a timer reprogramming bug
  • [18:39:53] <sakoman_> hope you find it!
  • [18:40:02] <sakoman_> off to lunch now, back in a bit
  • [18:40:04] <paul_pwsan> sakoman_: thanks
  • [18:41:54] <paul_pwsan> btw, if anyone gets a serial console hang, if they could try sending a sysrq-q (break + q, via serial) and report whether that works, and also whether, in the section reading "[in x nsecs]", whether x is positive or negative, that would be very helpful
  • [18:42:28] <paul_pwsan> btw "break + q" is CTRL-a + f + q in minicom
  • [18:42:33] <jkridner|work> can you give the sequence for whatever terminal package you are using (minicom?)?
  • [18:42:36] <paul_pwsan> hehe
  • [18:42:42] <jkridner|work> ah, beat me to the punch!
  • [18:42:44] <jkridner|work> :)
  • [18:42:58] * mru wishes his crash was that easy to debug
  • [18:43:35] <khasim> I thought it was due to Muxing between USB and UART3 pins but that didnt turn out to be
  • [18:43:59] <paul_pwsan> khasim: there could be multiple issues...
  • [18:44:12] <khasim> I then thought UART3 being in peripheral domain might be handled in a different way but that works on other boards
  • [18:44:39] <koen> paul_pwsan: you're in luck, my beagle just hung: http://rafb.net/p/kQQZSo89.html :)
  • [18:44:54] <paul_pwsan> koen: hehe, sweet :-)
  • [18:45:06] <paul_pwsan> yeah, looks like the timer reprogramming issue
  • [18:45:10] <koen> minicom in screen: ctrl+a a f q
  • [18:45:50] <paul_pwsan> koen: thanks much. patches here don't quite fix it yet but, still working on it
  • [18:45:55] <mru> what issue is that?
  • [18:46:07] <mru> and what other effects might it have?
  • [18:46:12] <koen> serial console hang
  • [18:46:39] <mru> "timer reprogramming issue" sounds a little more specific
  • [18:47:20] <khasim> paul_pwsan: I have tried configuring timer to auto load instead, this didnt help
  • [18:47:21] <paul_pwsan> mru: it can cause serial console hangs, and i think it is one source (not all) of occasional hangs on boot
  • [18:47:22] <jkridner|work> can someone try to d/l http://www.beagleboard.org/uploads/HARRY.YUV ?
  • [18:47:35] <jkridner|work> it is 48MB, but Khasim is having a difficult time downloading it.
  • [18:48:07] <paul_pwsan> khasim: my suspicion currently is focused on f620756fb38895c1095b797f8fdf74243e128a1d
  • [18:48:13] <koen> jkridner|work: 27% [================================> ] 12,817,864 602K/s eta 44s
  • [18:48:24] <mru> jkridner|work: no problem here so far with that file
  • [18:48:26] <khasim> paul_pwsan: When I had a Lauterbach connected I found that no timer or prcm interrupts were getting generated
  • [18:48:30] <mru> what is it?
  • [18:49:42] <paul_pwsan> mru: not 100% sure yet, but suspect there are at least two bugs in the GPTIMER reprogramming code
  • [18:49:50] <mru> too bad we only have arm9 lauterbach stuff at work
  • [18:50:22] <mru> paul_pwsan: and these cause serial lockup and boot hangs?
  • [18:50:24] <mru> nothing else?
  • [18:50:51] <paul_pwsan> mru: one is that the GPTIMER TLDR register occasionally is programmed with 0xffffffff, contra TRM 16.2.4.7
  • [18:51:11] <khasim> mru: Lauterbach is not helping as I don't find any reason for crash, but putting a break points at ISRs didnt hit
  • [18:51:34] <paul_pwsan> khasim: try the sysrq-q thing next time you hit it
  • [18:52:08] <khasim> paul_pwsan: ok,
  • [18:52:48] <paul_pwsan> mru: i suspect the other bug is related to not accounting for write posting latency, but again, not 100% sure yet. the current patch set here doesn't quite fix the issue
  • [18:53:17] <khasim> did some one try to download the file? http://www.beagleboard.org/uploads/HARRY.YUV
  • [18:53:37] <mru> khasim: yes, no problem
  • [18:53:42] <koen> khasim: yes, no problem
  • [18:53:45] <khasim> mru: thanks
  • [18:53:47] <koen> hmmm
  • [18:53:52] <koen> there's an echo here :)
  • [18:54:10] <khasim> mru: may be my internet is slow
  • [18:54:45] <khasim> will catch up later - bye all
  • [18:54:51] <paul_pwsan> bye
  • [19:09:35] <koen> paul_pwsan: are your patches online somewhere?
  • [19:10:18] <mru> they've been posted to the linux-omap mailing list
  • [19:10:22] <mru> and they're in my git
  • [19:10:35] <koen> his new and untested patches :)
  • [19:10:42] <koen> I already have the v2 twl patches
  • [19:10:58] <mru> oh, another set of patches... must have missed something
  • [19:10:59] <koen> http://www.pwsan.com/omap/twl4030_set_v2b.tar.gz
  • [19:11:01] <paul_pwsan> koen: haven't posted them yet, just discovered that they need more work...
  • [19:11:55] * koen again notices a shortage of soapy stuff in his travel bag
  • [19:12:05] <koen> $*(@*$(@ airport 'security'
  • [19:12:48] <paul_pwsan> khasim: assuming that you're reading the logs - if someone there has irq -33 patches, perhaps he/she could post them to the list or at least on #beagle
  • [19:13:41] <mru> where's the i2c 400kHz patch again?
  • [19:14:29] <paul_pwsan> mru: there isn't one any more, just modify by hand in arch/arm/mach-omap2/board-omap3beagle.c:42 or so
  • [19:14:43] <mru> ok
  • [19:15:31] <paul_pwsan> so far afaik, you're the only one still reporting consistent problems with 2.6MHz I2C w/ beagle; i think sakoman's issues were fixed by the i2c-omap/twl4030 patches
  • [19:15:34] <koen> mru: http://www.sakoman.net/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff_plain;h=12d6504334a830774ff1d42cee4b7296ac9fb7d2
  • [19:16:24] <mru> I have no evidence that my problem would be related to i2c in any way
  • [19:16:32] <mru> it's just something I haven't tried
  • [19:19:21] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [19:21:25] * Ragha (n=Ragha@nat/ti/x-3eb6a579a4c9d68a) has joined #beagle
  • [19:21:41] * nato_havoc (n=walter@host121.natpool.mwn.de) Quit (Remote closed the connection)
  • [19:23:40] <mru> and crash
  • [19:25:05] <koen> "watch tv" in myth is a foolproof way of triggering it as well
  • [19:25:21] <paul_pwsan> koen: the timer reprogramming bug?
  • [19:25:25] * koen wonders why the colours in the preview are inverted
  • [19:25:32] <koen> paul_pwsan: no a crash
  • [19:25:41] <paul_pwsan> oh
  • [19:29:13] * RogerMonk (n=a0740758@nat/ti/x-100cbf9b68267a68) Quit (Remote closed the connection)
  • [19:31:35] <mru> debugging suggestions would be appreciated
  • [19:35:39] <paul_pwsan> mru: what's the issue? start watching tv in mythtv, then system hangs?
  • [19:35:41] <mru> what methods exist for debugging sudden total kernel lockups?
  • [19:35:48] <ds2> SAK
  • [19:35:50] <ds2> JTAG
  • [19:36:00] <ds2> KGDB if you are really lucky
  • [19:36:47] <mru> as far as I can tell, it's quite dead
  • [19:37:02] <paul_pwsan> if it's reproducible, then you can start adding printk's in the kernel... the linus torvalds way
  • [19:37:13] <mru> no response to sysrq, heartbeat led stops flashing, watchdog kicks in if enabled
  • [19:37:23] <mru> paul_pwsan: sure, but where?
  • [19:37:29] <mru> there are millions of lines of code
  • [19:38:41] <paul_pwsan> mru: the nmi watchdog kicks in?
  • [19:38:54] <paul_pwsan> or some other watchdog
  • [19:39:00] <mru> whatever sits on /dev/watchdog
  • [19:39:11] <mru> CONFIG_OMAP_WATCHDOG
  • [19:40:04] <paul_pwsan> i see, so the board just reboots at that point, no messages?
  • [19:40:12] <mru> nothing
  • [19:40:17] <mru> reboot, yes
  • [19:40:33] <mru> a minute after it dies
  • [19:41:57] * Olipro is now known as Olipro|
  • [19:42:01] <ds2> is the WDT enabled?
  • [19:42:18] * Olipro| is now known as \\Test\
  • [19:42:48] <paul_pwsan> here are some thoughts, don't know how useful they would be. not sure what mythtv's system call volume is, but you might be able to strace mythtv, and see if the hang is triggered near a consistent sequence of system calls.
  • [19:42:56] * \\Test\ is now known as Olipro
  • [19:43:25] <paul_pwsan> that could help narrow down the part of the kernel that is causing problems.
  • [19:44:07] <paul_pwsan> don't know anything about mythtv, but would assume that it uses the display subsystem and dma code heavily.
  • [19:45:24] <paul_pwsan> so you could try putting some printk()s in that code. that takes it down from millions of lines to about 15k lines that are perhaps more likely than other areas to be implicated in the problem.
  • [19:46:08] <paul_pwsan> not sure if you are using the DSP, but if so, the dsplink code would also be good targets for printk()s.
  • [19:48:14] <paul_pwsan> one other idea that you may wish to try, just to be sure: in arch/arm/mach-omap2/pm34xx.c:pwrdms_setup(), change 'pwrst->next_state = PWRDM_POWER_RET' to 'pwrst->next_state = PWRDM_POWER_ON'
  • [19:49:33] <mru> it's not only mythtv
  • [19:49:41] <mru> plain old ffmpeg triggers it too
  • [19:49:56] <mru> seems to be worse if you're touching the framebuffer at the same time
  • [19:50:12] <mru> not using the dsp
  • [19:51:03] <paul_pwsan> does it affect ffmpeg when it is rendering to an in-memory buffer (not the framebuffer)? i.e., just computing, no IO?
  • [19:51:22] <mru> yes
  • [19:51:29] <mru> usually takes longer though
  • [19:51:49] <mru> there's always io of course
  • [19:51:54] <mru> reading the file
  • [19:52:35] <paul_pwsan> might want to try hacking it to eliminate all IO from the equation, maybe just decode the same frame over and over, if that is possible
  • [19:53:22] <mru> or use a small file in a tmpfs
  • [19:54:28] <paul_pwsan> true. it would be nice to remove as much kernel code as possible, to see if the lockup is reproducible when the system is in userspace the whole time
  • [19:54:50] <mru> any lockup is either kernel or hardware bug
  • [19:54:57] <mru> I'm hoping for the former
  • [19:54:57] <paul_pwsan> exactly
  • [19:56:04] <paul_pwsan> one other thing...
  • [19:56:24] <paul_pwsan> not sure how long the period is between starting ffmpeg and locking up,
  • [19:56:47] <mru> with ffmpeg, it usually takes a few minutes
  • [19:57:05] <mru> with a framebuffer player, it often locks up after only a few seconds
  • [19:57:24] <paul_pwsan> but if you have some way of periodically cooling the omap and twl4030, that would be interesting to try. like a can of freeze spray... not sure if they still sell that stuff?
  • [19:59:07] <mru> they sell it, but I don't have any at home
  • [20:00:58] <mru> what's the temperature rating on these components?
  • [20:08:28] * Linitrofe__ (n=aaguirre@134-38-50.adsl.terra.cl) has joined #beagle
  • [20:15:37] * cian (n=cian@cian.ws) Quit (Remote closed the connection)
  • [20:24:30] * Linitrofe_ (n=aaguirre@200-31-112.adsl.terra.cl) Quit (Read error: 110 (Connection timed out))
  • [20:24:38] <koen> mru: what's the status of the neon stuff going into ffmpeg svn?
  • [20:34:18] <paul_pwsan> here's another weird beagle problem i'd like to know if anyone else sees
  • [20:34:41] <mru> let's hear it
  • [20:34:56] <paul_pwsan> about once every 30 or so cold power cycles, nothing happens
  • [20:35:01] <paul_pwsan> upon applying power
  • [20:35:05] <mru> never seen that one
  • [20:35:10] <mru> what board version?
  • [20:35:12] <paul_pwsan> no x-loader message, etc.
  • [20:35:13] <paul_pwsan> b4
  • [20:35:21] <mru> b here
  • [20:36:08] <paul_pwsan> the board is connected to a lab power supply, and when this happens, the board consumes about 80mA of current. normal usage at that point is about 226mA of current
  • [20:38:17] <koen> haven't seen that either
  • [20:38:26] <koen> but then again, I don't do a lot of cold boots
  • [20:38:39] <koen> I do get ecc error about 1 in 7 boots
  • [20:38:48] <koen> and non working usb about 50% of the boots
  • [20:39:06] <mru> I get bad usb from time to time
  • [20:39:22] <mru> less than one in 5
  • [20:41:47] <mru> koen: do you have NO_HZ enabled?
  • [20:47:10] * RogerMonk (n=a0740758@nat/ti/x-0e857410c068658b) has joined #beagle
  • [21:15:12] <paul_pwsan> quick update on the timer reprogramming bug for anyone following on the channel or the logs
  • [21:15:49] <paul_pwsan> just tried reverting 7622c36330e1fd365dc258bbb40996ec9a1539b6 and f620756fb38895c1095b797f8fdf74243e128a1d -- and the problem still occurred
  • [21:16:58] <paul_pwsan> still looking into it
  • [21:20:39] <jkridner|work> if you are seeing strange H/W behavior, it would be handy if you could run the tests setup by Khasim on code.google.com. I just want to make sure that we are clear if we are missing any board issues during manufacturing.
  • [21:22:13] * cian (n=cianh@cian.ws) has joined #beagle
  • [21:22:37] <paul_pwsan> jkridner|work: which tests are those?
  • [21:24:16] <jkridner|work> ugh, looks like they are in flux: http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnostics
  • [21:24:41] <jkridner|work> they are reference x-load/u-boot/kernel images.
  • [21:25:08] <jkridner|work> old versions without all functions, but hopefully known working.
  • [21:25:31] <jkridner|work> if funny behavior is seen on these images, the board doesn't ship.
  • [21:29:43] <jkridner|work> any comments here about having Kdrive support for the OpenGLES drivers rather than X.org?
  • [21:29:57] <mru> can we only have one?
  • [21:31:26] <suihkulokki> iirc kdrive is getting depreceated
  • [21:31:43] <mru> not enough bloat?
  • [21:32:44] <suihkulokki> not enough people keeping it upto date
  • [21:33:11] <suihkulokki> generally X is suffering badly from lack of manpower outside the intel drivers..
  • [21:33:41] * zoobab (i=zoobab@vic.ffii.org) has joined #beagle
  • [21:33:46] <zoobab> hi
  • [21:33:54] <mru> maybe just as well, I didn't at all like some directions people were trying to take it
  • [21:33:55] * BThompson (n=BThompso@nat/ti/x-43907ea6eea9b597) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [21:34:31] <zoobab> can you put a harddisk on the Beagle?
  • [21:34:40] <Crofton> usb hard disk ....
  • [21:34:43] <zoobab> ok
  • [21:34:58] <zoobab> same for CD/DVD player
  • [21:35:06] <mru> we should make that a #1 faq somewhere
  • [21:35:25] <mru> I and koen had to answer that question countless times at LRL
  • [21:35:47] <zoobab> LRL?
  • [21:36:19] <zoobab> is there a port for OpenWRT already?
  • [21:36:25] <zoobab> or debian?
  • [21:36:42] <mru> debian on arm is a sad story
  • [21:36:46] <mru> I'm running gentoo
  • [21:37:04] <jkridner|work> Not that I know of, but I've heard rumblings on getting OpenWRT started.
  • [21:37:23] <mru> others like openembedded/angstrom
  • [21:37:24] <jkridner|work> I think there have been some Debian attempts and certainly Ubuntu attempts.
  • [21:37:38] <jkridner|work> Angstrom is the most complete distro for Beagle today.
  • [21:37:51] <mru> the trouble with debian is that they, apparently, insist on building everything on the target
  • [21:37:54] <jkridner|work> I'm a Gentoo fan who is on the edge of conversion with some reservations.
  • [21:38:22] <mru> and that includes *all* arm targets
  • [21:38:39] <mru> so you're stuck with stuff that can be compiled on a toaster
  • [21:39:16] * mru thinks debian has far too many self-imposed rules
  • [21:39:57] <jkridner|work> I thought I heard that even the RedHat folks could deal with some cross-compilation.
  • [21:40:06] <ds2> yes, please Kdrive support
  • [21:40:18] <jkridner|work> Do you think that is just Debian's wish-list or requirement?
  • [21:40:18] <ds2> and full acceleration on 2D too ;)
  • [21:40:25] <suihkulokki> sigh
  • [21:40:30] <mru> redhat doesn't have philosophical/religious objections to doing certain things
  • [21:40:31] <jkridner|work> OpenVG for 2D acceleration.
  • [21:41:09] <zoobab> what about mplayer benchmarks? for DivX, DVD playing and al
  • [21:41:22] <jkridner|work> let's go back to that USB FAQ before we get the Debian people in too much of an uproar. :)
  • [21:41:45] * mru likes causing a stir
  • [21:41:48] <jkridner|work> Anytime you are wondering if a certain peripheral is available for Beagle, always ask if you can connect it over USB.
  • [21:42:01] <Linitrofe__> what's the problem with kdrive?
  • [21:42:04] <ds2> easier said then done
  • [21:42:40] <ds2> unless you have droves of people volunteering to clean up the musb driver ;)
  • [21:43:03] <mru> zoobab: we still haven't quite worked out how to best implement video overlay drivers
  • [21:43:17] <jkridner|work> I'm expecting the reinforcements to at least trickle in!
  • [21:43:24] <mru> once drivers are done, mplayer should run nicely
  • [21:43:30] <zoobab> shit there is no ethernet
  • [21:43:38] <calculus> usb!
  • [21:43:39] <mru> zoobab: USB!
  • [21:43:42] <ds2> mru: there should be drivers using a V4L interface
  • [21:43:43] <jkridner|work> USB! :)
  • [21:44:05] <mru> ds2: there doesn't exist a single player capable of using those drivers
  • [21:44:12] <ds2> why use ethernet? do you also want to have a soldering iron built into your battery powered phone? :)
  • [21:44:24] <ds2> mru: didn't say there was userland code for it..just saying there is a driver ;)
  • [21:44:35] <mru> I have a framebuffer-based driver
  • [21:44:44] <mru> slight hack on the linux-omap git tree
  • [21:44:48] <mru> it's working fine
  • [21:45:29] <mru> but again, afaik only my test player knows how to use it
  • [21:45:49] <jkridner|work> zoobab: as you can see, things are evolving. now is the time to take up a goal and solidify it for other people given all of the other collaborators.
  • [21:45:59] <ds2> it is unfortunate there are 234414234343242 different ways of doing overlays on all the different arm devices :(
  • [21:46:17] <mru> is that all?
  • [21:50:37] <jkridner|work> so, is there anyone who is going to go nuts with only K-drive and fbdev support for OpenGL/OpenVG? let me know on the mailing list if not while I'm active here.
  • [21:52:09] <mru> why is supporting full Xorg a problem?
  • [21:53:21] <jkridner|work> I don't know that it is a problem, only that I'm told it isn't part of the plan.
  • [21:53:32] <jkridner|work> I need to know if I need to raise a fuss.
  • [21:53:59] <Linitrofe__> I'm confused, what's the problem with Kdrive?
  • [21:54:00] <mru> binary-only drivers are always cause for fuss
  • [21:54:29] <Linitrofe__> Tehre is a framebuffer already running for the OMAP?
  • [21:54:47] <mru> Linitrofe__: sure
  • [21:54:51] <Linitrofe__> so?
  • [21:55:15] <mru> X is more fun than raw framebuffer
  • [21:55:37] <Linitrofe__> But X just talk with the framebuffer (if you use that way)
  • [21:55:57] <mru> that's not (very) accelerated
  • [21:55:58] <Linitrofe__> or we are talking about a driver for the powerVR peripheral?
  • [21:56:13] <jkridner|work> we are talking about a driver for the PowerVR.
  • [21:56:30] <Linitrofe__> Oh! ok
  • [21:56:41] <jkridner|work> do we need graphics in a relocatable window in anything other than K-drive?
  • [21:57:20] <jkridner|work> I'm hearing no great outcry. Sounds like K-drive really could be good enough (in addition to fbdev).
  • [21:57:40] <mru> OUTCRY
  • [21:57:53] <Linitrofe__> Always will be someone that ones full support for the HW
  • [21:57:54] <jkridner|work> tell me.
  • [21:58:05] <jkridner|work> why do we need Xorg?
  • [21:58:05] <Linitrofe__> *wants
  • [21:58:13] <mru> why do we not need it?
  • [21:58:19] <Linitrofe__> haha
  • [21:58:21] <jkridner|work> (must play devil's advocate to generate a *real* answer.)
  • [21:58:22] <Linitrofe__> you probe my point
  • [21:59:14] <Linitrofe__> What advantage present full Xorg over Kdrive?
  • [21:59:25] <jkridner|work> It isn't plan-of-record and if I don't have an answer as to why it is needed, other than we just want something else, then people start to bring up cost/benefit analysis, blah, blah...
  • [21:59:33] <mru> maintained, not stripped to the bare minimum
  • [21:59:45] <Linitrofe__> So?
  • [22:00:03] * mru thinks they should just release the chip specs and stop fussing
  • [22:00:12] <Linitrofe__> I'm not sure if it is stripped, Xorg is builded over the Kdrive bases (I'm right?)
  • [22:00:24] * jkridner|work smiles helplessly.
  • [22:00:37] <Linitrofe__> PowerVR is a long history of struggling
  • [22:00:37] <mru> what little information there is about kdrive suggests it's a stripped-down version of Xorg
  • [22:01:28] <mru> rumour has it powervr is a fairly programmable architecture
  • [22:01:59] <mru> and that the oh-so-secret drivers contain code implementing opengles
  • [22:02:32] <mru> now imagine if we had the specs for the actual hardware
  • [22:02:55] <mru> I'm sure it could be used for other interesting things than 3d rendering
  • [22:03:24] <Linitrofe__> such as?
  • [22:03:59] <ds2> with X.org, you can also test your media storage device's reliability
  • [22:04:06] <ds2> :)
  • [22:04:06] <mru> Linitrofe__: video decoding of course
  • [22:04:31] <mru> I'm not interested in hearing examples of what you can do without Xorg
  • [22:04:42] <mru> the fact is, there are things Kdrive can't do
  • [22:04:47] <ds2> plus it is insurance that no one will ever deploy stuff with the internal flash... afterall, what's 256M to an full blown Xorg setup...
  • [22:04:49] <mru> why should we prevent people doing those things
  • [22:05:05] <ds2> enuff sarcasm for the day
  • [22:05:13] <mru> ds2: the core Xorg server isn't *that* bit
  • [22:05:15] <mru> big
  • [22:05:36] <ds2> and a Geo metro isn't *that* small ;)
  • [22:07:23] <paul_pwsan> until major linux distributions start shipping with Kdrive as their X server, X.org support would be much better
  • [22:08:07] <jkridner|work> maybe that is the killer. What distros do and don't support Kdrive for X.org?
  • [22:08:18] <jkridner|work> Ubuntu? Angstrom? Debian? Gentoo?
  • [22:08:39] <jkridner|work> for = or
  • [22:09:29] <mru> gentoo seems to have (some) support for both
  • [22:09:51] <paul_pwsan> last i checked, both fedora and ubuntu use X.org by default
  • [22:10:03] <ds2> isn't fedora x86 only?
  • [22:10:17] <Linitrofe__> Ubuntu has Xephyr wich is based on Kdribe, but is not Kdrive
  • [22:10:24] <mru> fedora has a little-known arm port
  • [22:10:28] <Linitrofe__> but everything is based on Kdrive so...
  • [22:10:32] <mru> not even fedora people usually know of it
  • [22:10:43] <ds2> ah
  • [22:12:14] <jkridner|work> quickie list of ARM distros: http://beagleboard.blogspot.com/2008/05/distros-for-beagle.html
  • [22:16:42] <jkridner|work> If you have a solid argument for why Kdrive alone just makes you angry and prevents you from building your dream app, please send it to the mailing list.
  • [22:16:47] * jkridner|work is off for dinner.
  • [22:17:13] <mru> I don't have an argument right now
  • [22:17:44] <mru> because I don't know what I might want to do in the future
  • [22:23:06] * rsalveti (n=salveti@200.184.118.132) Quit (Read error: 113 (No route to host))
  • [22:23:43] * rsalveti (n=salveti@189.70.143.203) has joined #beagle
  • [22:32:55] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [22:35:16] * prpplague (n=dave@mail.americanmicrosystems.com) Quit ("Leaving")
  • [22:38:54] <calculus> I think just limiting things to kdrive would be a poor choice... it is enough that it is already a binary driver
  • [22:39:29] <mru> limitations are bad
  • [22:39:41] <mru> especially when you don't know the consequences of them
  • [22:43:34] <calculus> there you go jkridner ^^, in a nutshell
  • [22:44:06] <mru> I'm still trying to find out precisely what kdrive is
  • [22:44:13] <mru> and what it is not
  • [22:44:28] <mru> information seems very sparse
  • [22:44:43] <calculus> I don't think kdrive would let me do distributed multiheaded x servers
  • [23:08:31] * docelic (n=docelic@78.134.199.199) Quit ("http://www.spinlocksolutions.com/")
  • [23:26:13] * Ragha (n=Ragha@nat/ti/x-3eb6a579a4c9d68a) Quit ("Now if you will excuse me, I have a giant ball of oil to throw out my window")
  • [23:34:16] * Lynet (n=larsg@062016224237.customer.alfanett.no) has joined #beagle
  • [23:41:20] <mru> most curious
  • [23:41:39] <mru> if I disable some of the neon functions in ffmpeg, the crashes go away
  • [23:43:38] * KSoze is now known as KeyserSoze
  • [23:47:43] <paul_pwsan> mru: are you running with the change to pm34xx.c to set all powerdomain states to PWRDM_PWRST_ON ?
  • [23:49:03] * Linitrofe__ (n=aaguirre@134-38-50.adsl.terra.cl) Quit ("Ex-Chat")
  • [23:52:54] * RogerMonk (n=a0740758@nat/ti/x-0e857410c068658b) Quit (Remote closed the connection)