• [03:58:40] * BeagleLogBotTest (n=PircBot@ec2-75-101-156-174.compute-1.amazonaws.com) has joined #beagle
  • [03:58:40] * Topic is 'Welcome to #Beagle | Discussion about the OMAP3 Beagle Board - http://beagleboard.org | Beagle search tools are on #dashboard at irc.gimp.org, NOT here ;) | Log is at http://www.beagleboard.org/irclogs'
  • [03:58:40] * Set by jkridner on Tue Jun 10 00:33:18 CDT 2008
  • [04:01:45] * RobotGuy (n=Dale@dsl093-038-072.pdx1.dsl.speakeasy.net) has joined #beagle
  • [04:08:21] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [04:30:46] * shoragan_ (n=shoragan@sicherheitsschwankung.de) has joined #beagle
  • [04:31:49] * shoragan (n=shoragan@debian/developer/shoragan) Quit (Read error: 104 (Connection reset by peer))
  • [04:40:59] * shoragan_ (n=shoragan@sicherheitsschwankung.de) Quit (Remote closed the connection)
  • [04:42:24] * shoragan_ (n=shoragan@sicherheitsschwankung.de) has joined #beagle
  • [04:58:28] * bazbel1 (n=a0192809@nat/ti/x-0bd1309a59050962) Quit ("Leaving.")
  • [05:13:50] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [05:27:21] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [05:36:44] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [07:05:15] * RogerMonk (n=a0740758@nat/ti/x-12e0301c3fadd5c5) Quit (Remote closed the connection)
  • [07:17:43] <koen> hmmmm
  • [07:17:52] <koen> how do I enable more than one plane in omapfb?
  • [07:51:37] <mru> koen: video=omapfb:vram=2M:vram=4M or similar on the kernel command line
  • [07:53:39] <koen> Kernel command line: console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 rootdelay=2 rootfstype=ext3 video=omapfb:vram:3M:vram:4M
  • [07:53:52] <koen> ah, I see what I did wrong :)
  • [07:56:12] <koen> hmmm
  • [07:56:13] <koen> console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 rootdelay=2 rootfstype=ext3 video=omapfb:vram=2M:vram=6M
  • [07:56:36] <koen> omapfb: Framebuffer initialized. Total vram 1572864 planes 1
  • [07:56:36] <koen> omapfb: Pixclock 48000 kHz hfreq 40.5405 kHz vfreq 51.3 Hz
  • [07:57:06] <mru> probably not enough dma memory for the second plane
  • [07:57:23] <koen> 6 megs is not enough?
  • [07:57:29] <mru> it should be
  • [07:57:36] <koen> I have 8MB dma available
  • [07:58:15] <mru> what resolution are you running?
  • [07:59:30] <koen> 1024x768
  • [08:00:07] <mru> then 1572864 is enough for the first plane
  • [08:00:19] <koen> what does 'cat /proc/cmdline' say for your beagle with overlays?
  • [08:01:51] <mru> for the second plane you'll want enough memory for two video frames
  • [08:02:10] <koen> I boot with video=omapfb:vram=2M:vram=6M
  • [08:02:33] <mru> for 1280x720 video that becomes 3686400
  • [08:09:49] * RogerMonk (n=a0740758@nat/ti/x-94568d9c36c75368) has joined #beagle
  • [08:10:17] <koen> video=omapfb:vram:2M,vram:4M'
  • [08:10:21] <koen> there we go :)
  • [08:11:41] * rsalveti (n=salveti@189.70.143.68) Quit (Read error: 110 (Connection timed out))
  • [08:11:56] * rsalveti (n=salveti@189.70.140.74) has joined #beagle
  • [08:12:22] <mru> you might want to pull from the player repo
  • [08:12:32] <mru> I just checked in something nice
  • [08:12:50] <koen> omapfb: Framebuffer initialized. Total vram 6291456 planes 2
  • [08:12:55] <mru> that's better
  • [08:17:27] <koen> does your scale code keep aspect?
  • [08:17:34] <mru> not yet
  • [08:18:34] <koen> it's decoding as fast as it can, is that solved by your thread commit?
  • [08:18:46] <mru> yes
  • [08:19:00] <mru> there would be no point to it otherwise
  • [08:19:23] <mru> now we just need to put the display thread on the dsp
  • [08:28:16] <koen> mru: http://amethyst.openembedded.net/~koen/beagleboard/beagle-image-corruption.avi
  • [08:28:31] <koen> that's what I saw mith mplayer an now with omapfbplay
  • [08:40:18] * esden`aw` (n=esden@repl.esden.net) has joined #beagle
  • [08:42:07] * esden`away (n=esden@repl.esden.net) Quit (Read error: 104 (Connection reset by peer))
  • [08:50:48] * Olipro (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [08:52:18] * RobotGuy (n=Dale@dsl093-038-072.pdx1.dsl.speakeasy.net) Quit ("I'll be back..")
  • [09:40:36] * lardman (n=lardman@enpc-smm11.bath.ac.uk) has joined #beagle
  • [09:52:59] * shoragan_ is now known as shoragan
  • [09:56:31] * jkridner|work1 (n=a0321898@nat/ti/x-68f78a11edec7e23) has joined #beagle
  • [09:56:36] * jkridner|work (n=a0321898@nat/ti/x-d809952298085f81) Quit (Remote closed the connection)
  • [11:26:57] <jkridner> good morning
  • [11:29:07] <koen> hey jkridner
  • [11:33:12] <koen> jkridner: I get 16-28 fps on 720p mpeg4 video with mrus omapfbplayer
  • [11:33:27] <jkridner> amazing.
  • [11:33:57] <jkridner> puts me in awe with what could be done once the DSP and accelerators are engaged.
  • [11:34:26] <jkridner> I saw mru's comment about image corruption.
  • [11:34:54] <jkridner> also, without margin over 24fps, it is difficult to play any real videos.
  • [11:35:11] <jkridner> is this still software based YUV conversion?
  • [11:35:21] <koen> the 720p video we test with (big buck bunny) is 24fps
  • [11:36:37] <koen> see http://git.mansr.com/?p=omapfbplay;a=blob;f=omapfbplay.c;h=acca5c3c89a18ef9888518da3ab667ce2a211525;hb=HEAD :)
  • [11:36:56] <koen> neon based yuv conversion
  • [11:37:08] <jkridner> but if you are seeing 16-28 fps, then it must not play in real-time.
  • [11:37:21] <koen> there is some headroom since we can bump the cpu to 600MHz
  • [11:37:42] <jkridner> ah. k.
  • [11:37:50] <koen> it buffers 45 frames, so it's nearly realtime with 500MHz
  • [11:38:20] <jkridner> do you see the same corruption issue?
  • [11:38:43] <koen> http://amethyst.openembedded.net/~koen/beagleboard/beagle-image-corruption.avi
  • [11:38:49] <koen> that's what I'm seeing
  • [11:43:35] <koen> jkridner: one week left to fix that image corruption :)
  • [11:44:13] <jkridner> giving it 50/50 odds?
  • [11:45:31] <koen> no idea
  • [11:45:40] <koen> I don't know where the problem lays
  • [11:45:54] <koen> could be a compiler issue, an ffmpeg issue, a kernel issue, etc
  • [11:46:37] <jkridner> I suppose you've integrated this into the latest Angstrom version?
  • [11:46:59] <jkridner> (just wondering if there is a way to fan it out for others to look at the issue.)
  • [11:47:30] <koen> get the latest uImage from OE, change bootargs, 'opkg install omapfbplay'
  • [11:54:32] * lardman is now known as lardman|lunch
  • [11:58:39] <koen> jkridner: http://amethyst.openembedded.net/~koen/beagleboard/overlay/
  • [12:05:34] * Bari\ (n=ly@c-24-12-190-159.hsd1.il.comcast.net) Quit (kubrick.freenode.net irc.freenode.net)
  • [12:05:34] * bjdooks (n=ben@trinity.fluff.org) Quit (kubrick.freenode.net irc.freenode.net)
  • [12:07:55] * docelic (n=docelic@78.134.205.212) has joined #beagle
  • [12:08:15] * bjdooks (n=ben@trinity.fluff.org) has joined #beagle
  • [12:08:15] * Bari\ (n=ly@c-24-12-190-159.hsd1.il.comcast.net) has joined #beagle
  • [12:10:19] <koen> jkridner: I made a static binary of the player to avoid pulling in a zillion packages
  • [12:11:05] <jkridner> saw that. it will help.
  • [12:13:31] * docelic_ (n=docelic@78.134.194.163) has joined #beagle
  • [12:16:44] <koen> binary with debug symbols: http://amethyst.openembedded.net/~koen/beagleboard/overlay/omapfbplay.bz2
  • [12:29:21] * BThompson (n=BThompso@nat/ti/x-c3655612676bd071) has joined #beagle
  • [12:29:57] <koen> jkridner: http://groups.google.com/group/beagleboard/browse_thread/thread/9b8025fc15120fd9#
  • [12:30:44] <jkridner> thanks!!
  • [12:31:00] * docelic (n=docelic@78.134.205.212) Quit (Read error: 110 (Connection timed out))
  • [12:34:04] <koen> already 405 subscribers to the list :)
  • [12:35:23] * evalenti (n=evalenti@dasasob.nokia.com) has joined #beagle
  • [12:36:27] <koen> hey Eduardo
  • [12:36:34] <evalenti> hello Koen
  • [12:37:05] <koen> evalenti: I think most people here work with the git kernel, which doesn't have svideo support yet
  • [12:39:27] * likewise (n=chatzill@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [12:39:31] <likewise> hi
  • [12:40:15] <evalenti> koen: hummm.. that's what I expected :)... But, anyway, about the output in test mode from the u-boot? do you guys get correct output?
  • [12:40:27] <evalenti> koen: or never tried ?
  • [12:42:45] <ldesnogu> koen: regarding your mplayer issue, you did not make it clear: is mru having the same issue?
  • [12:45:59] <koen> ldesnogu: mru said he had trouble like that in the past
  • [12:46:34] <likewise> hi koen
  • [12:46:51] <koen> hey likewise
  • [12:47:48] <ldesnogu> koen: "had", so he doesn't experience this anymore...
  • [12:50:35] <koen> it seems so....
  • [12:50:54] <koen> I hope people can reproduce what I'm seeing and point to the cause
  • [12:52:55] <ldesnogu> my board hasn't arrived yet, hopefully within 2 weeks, so I won't be able to help :(
  • [12:53:51] <ldesnogu> there's perhaps something you could test to rule out compiler bug in ffmpeg: convert the video with ffmpeg to a simple format, and compare that to what mru gets
  • [13:07:08] * RobotGuy (n=Dale@dsl093-038-072.pdx1.dsl.speakeasy.net) has joined #beagle
  • [13:09:47] * johnnybug (n=jconnoll@ip-64-32-229-194.dsl.nyc.megapath.net) has joined #beagle
  • [13:22:41] <Crofton> bother, some kind of usb error when I try load the usrp firmware
  • [13:23:41] <koen> Crofton: urb_submit?
  • [13:24:04] * bazbell (n=a0192809@nat/ti/x-de3fc05950409632) has joined #beagle
  • [13:24:17] <Crofton> some kind of error detected by the usrp code
  • [13:24:22] <Crofton> let me poke around
  • [13:26:12] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has joined #beagle
  • [13:26:14] <Crofton> also, my pegasus sub nic disconnects and reconnects every few minutes
  • [13:29:10] <Crofton> http://rafb.net/p/9nOLD878.html
  • [13:29:31] <koen> Crofton: anything in syslog or dmesg?
  • [13:30:02] <Crofton> just the pegasus thing disconnet/reconnect
  • [13:30:12] <Crofton> need to look at that line of code
  • [13:31:23] * rsalveti (n=salveti@189.70.140.74) Quit (Read error: 110 (Connection timed out))
  • [13:32:25] * prpplague (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [13:32:32] <koen> prpplague: howdy!
  • [13:32:46] <prpplague> koen: greetings earthling
  • [13:34:12] * johnnybug is now known as jconnolly
  • [13:34:25] * rsalveti (n=salveti@200.184.118.132) has joined #beagle
  • [13:35:22] <prpplague> koen: new rev of the i/o board for our pda, causes the kernel not to boot, gotta debug that today :(
  • [13:36:25] <RogerMonk> guys... does "musb_bus_suspend 2129: trying to suspend as a_wait_vrise is_active=1" mean anything to you guys?
  • [13:36:54] <koen> try attaching a hub
  • [13:37:30] <RogerMonk> yep, attached...
  • [13:38:47] <koen> do you have another hub handy?
  • [13:38:47] <Crofton> http://rafb.net/p/Nx13rc56.html
  • [13:38:55] <Crofton> there is the line of code
  • [13:39:11] <Crofton> weird
  • [13:40:49] <koen> RogerMonk: or solder on the cap for VBUS
  • [13:40:57] <RogerMonk> hmm - I'll look - why you think related to hub - have you seen this error before?
  • [13:42:03] <koen> I get it when I don't have an hub with the caps attached
  • [13:42:25] <RogerMonk> ah-ok - can you remind me what value caps?
  • [13:43:54] <Crofton> a couple of uF's
  • [13:44:02] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [13:44:15] <koen> 2.2UF according to sakoman__s email
  • [13:44:38] <Crofton> http://rafb.net/p/FNncWp61.html
  • [13:44:43] <Crofton> i love ugly hacks
  • [13:46:27] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [13:46:28] * jconnolly (n=jconnoll@ip-64-32-229-194.dsl.nyc.megapath.net) Quit (Read error: 104 (Connection reset by peer))
  • [13:48:58] * lardman|lunch is now known as lardman
  • [13:50:31] * jconnolly (n=jconnoll@ip-64-32-229-194.dsl.nyc.megapath.net) has joined #beagle
  • [13:55:48] <Crofton> is the version of lilbusb in OE "funny"?
  • [13:55:58] * RogerMonk (n=a0740758@nat/ti/x-94568d9c36c75368) Quit (Remote closed the connection)
  • [13:57:00] * RogerMonk (n=a0740758@nat/ti/x-8ea2f720c09f387d) has joined #beagle
  • [13:57:51] <Crofton> f-word
  • [13:58:29] <Crofton> I am betting the usb_dev_handle sturct changes in libusb
  • [13:59:42] <Crofton> koen, do you know what is OE atm, I see libusb1 and a libusn-compat ....
  • [14:02:27] <koen> libusb1 is a rewrite of libusb
  • [14:02:44] <koen> and libusb-compat is a wrapper to provide compat
  • [14:03:57] <koen> Crofton: did you try recompiling the usrp tools?
  • [14:04:22] <Crofton> this should be built against the right stuff
  • [14:04:25] <Crofton> clean build yesterday
  • [14:04:51] <Crofton> I think the problem is that gnuradio assumes a struct layout, that changed
  • [14:05:03] <Crofton> is it easy to use the old libusb?
  • [14:05:36] <koen> if you statically link it....
  • [14:06:01] <koen> I PE'd libusbcompat, so the old one will get upgraded automatically
  • [14:06:21] <koen> the new libusb isn't using busy waiting and is async
  • [14:06:30] <koen> so it should be waaaaaaay faster on beagle and efika
  • [14:07:17] <Crofton> let me see if the struct exists
  • [14:07:25] <Crofton> and maybe I can patch
  • [14:12:15] <koen> hmmm
  • [14:12:56] <Crofton> at leaswt the code was properly commented .....
  • [14:13:06] <koen> 4gb sandisk ultra2 + reader for 20 euros
  • [14:17:04] <RogerMonk> hi guys... hub changed, capacitors added... same problem.... argh!!
  • [14:17:12] <Crofton> hmmm
  • [14:17:15] <Crofton> weird
  • [14:17:30] * Crofton curses people who depend on internal structs
  • [14:17:36] * RogerMonk (n=a0740758@nat/ti/x-8ea2f720c09f387d) Quit (Remote closed the connection)
  • [14:17:41] <koen> RogerMonk: tried powercycling the beagle?
  • [14:18:03] * RogerMonk (n=a0740758@nat/ti/x-a8d3d93cc3cc8e21) has joined #beagle
  • [14:18:12] <koen> RogerMonk: tried powercycling the beagle?
  • [14:18:28] <koen> RogerMonk: which u-boot, MLO and kernel are you using?
  • [14:18:32] <RogerMonk> 987987878 times! :)
  • [14:18:51] <RogerMonk> which MLO and u-boot should I be using?
  • [14:19:58] <koen> I have the NAND MLO from khasim and the u-boot 1.3.x from OE flashed to NAND
  • [14:21:21] <koen> ldesnogu: I'm going to try building a static omapfbplay with gcc 2007q3
  • [14:22:50] <ldesnogu> koen: you previously used 4.3.1?
  • [14:23:23] <koen> yes
  • [14:23:36] <ldesnogu> also note that static linking with 2008q1 and cortex-a8 is broken (can't remember if I said here I made CSL a bug report about that)
  • [14:23:38] <koen> since 2007q3 couldn't build a userspace that doesn't segfault
  • [14:23:44] <ldesnogu> :(
  • [14:23:53] * RogerMonk|linux (n=rmonkloc@host217-36-23-196.in-addr.btopenworld.com) has joined #beagle
  • [14:24:31] <ldesnogu> omafbplay = mplayer + mru patches?
  • [14:24:37] <koen> no
  • [14:24:50] <koen> ldesnogu: http://groups.google.com/group/beagleboard/browse_thread/thread/9b8025fc15120fd9/da62765f58ea1a3e#da62765f58ea1a3e
  • [14:25:05] * Noodlean (n=emil@foolean.ros.sgsnet.se) has joined #beagle
  • [14:26:05] <ldesnogu> oh ok it's ffmpeg + omap fb, nice :)
  • [14:26:40] <koen> nearly realtime 720p mpeg4 decoding at 500MHz
  • [14:27:14] * jconnolly (n=jconnoll@ip-64-32-229-194.dsl.nyc.megapath.net) Quit (Remote closed the connection)
  • [14:29:01] <ldesnogu> so it's a three step process : ffmpeg decodes to yuv420, omapfbplay makes yuv420 to yuv422, fb does yuv422 to rbg in HW
  • [14:29:07] <ldesnogu> did I get it right?
  • [14:29:48] <ldesnogu> I now understand why there were some DSP discussions recently :-)
  • [14:41:53] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [14:48:45] <koen> ldesnogu: right
  • [14:51:04] <ldesnogu> it would interesting to see what percentage of time the yuv2yuv consumes; it that's high enough (20% I'd say since you were talking of 48 fps) then using the DSP could bring to 60 fps
  • [14:58:28] <suihkulokki> .oO( yuv2rgb shader on SGX )
  • [14:58:43] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [15:00:41] <koen> ldesnogu: running oprofile now :)
  • [15:01:09] * RogerMonk (n=a0740758@nat/ti/x-a8d3d93cc3cc8e21) Quit (Remote closed the connection)
  • [15:04:39] <ldesnogu> :)
  • [15:08:35] * RogerMonk|linux (n=rmonkloc@host217-36-23-196.in-addr.btopenworld.com) Quit (Read error: 110 (Connection timed out))
  • [15:11:54] <koen> drat, it doesn't show up in the profile :(
  • [15:12:27] <koen> ldesnogu: http://rafb.net/p/rBsVUt44.txt
  • [15:12:41] <koen> I think it's in the 'disp_thread'
  • [15:18:24] * evalenti (n=evalenti@dasasob.nokia.com) Quit (Remote closed the connection)
  • [15:18:33] <ldesnogu> koen: yes it's been inlined in disp_thread
  • [15:18:38] <ldesnogu> so this is bad news
  • [15:19:42] <ldesnogu> ff_msmpeg4_decode_block looks bad
  • [15:22:06] <koen> ldesnogu: let me test with a 720p movie
  • [15:25:24] <ldesnogu> I have to go, I will read the log on the web :)
  • [15:26:06] <koen> ldesnogu: when you get back: http://rafb.net/p/WOWmjF59.txt
  • [15:26:46] <Crofton> koen, I've updated the ugly hack, hopefully, my hack to the hack gets us past the libsub problem
  • [15:26:47] <ldesnogu> that looks very similar
  • [15:26:55] <Crofton> crap, didn't compile
  • [15:27:24] <ldesnogu> the memset looks frightening
  • [15:27:49] * ldesnogu leaves for good :)
  • [15:30:42] * Crofton hacks the hack
  • [15:35:24] * dirk2 (n=dirk@F30e9.f.strato-dslnet.de) has joined #beagle
  • [15:45:04] <dirk2> I'm currently reading the discussion between RMK and Catalin at linux ARM kernel list about broken Cortex-A8 cache configuration output
  • [15:45:15] <dirk2> http://lists.arm.linux.org.uk/lurker/thread/20080709.212911.0ee5f449.en.html#20080709.212911.0ee5f449
  • [15:46:28] <dirk2> Anybody with an idea what rmk might mean with "I expect that we'll see the ARMv7 version being "revised" in an incompatible
  • [15:46:28] <dirk2> way in the near future"
  • [15:46:41] <dirk2> http://lists.arm.linux.org.uk/lurker/message/20080709.212911.0ee5f449.en.html
  • [15:46:48] <koen> it's just that time of the month
  • [15:47:08] <koen> when RMK cant win an argument he will just blast ARM for having changed designs in the past
  • [15:49:09] <dirk2> Hmm, do you think he talks about HW if he talks about "ARMv7 version revised"?
  • [15:51:13] <koen> he's just 'launisch' as you germans would say it
  • [15:51:40] <dirk2> ;)
  • [15:51:56] <dirk2> I understood it as "ARMv7 code in the kernel being revised", but may be this is wrong understanding
  • [15:52:12] <likewise> koen: you used gcc 4.3.1 already (for armv7)
  • [15:52:24] <likewise> koen: plus question mark :-)
  • [15:52:34] <koen> likewise: right, it's the most reliable compiler for userspace atm
  • [15:53:02] <koen> i.e. it results in a rootfs that doesn't segfault
  • [15:53:35] <likewise> koen: ah ok. khem just reports in a gcc-4.3.1 bug on #oe, "the -I target path is getting included even for the utilities that gcc builds for build machine like genmodes"
  • [15:54:22] <koen> dunno about that
  • [15:55:27] <likewise> ok, I just wondered if it was used at all
  • [15:59:37] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [16:04:05] <koen> likewise: angstrom will use 4.3.1 automagically if you select an armv7 machine
  • [16:11:53] * RogerMonk (n=a0740758@nat/ti/x-b9e375c20318d3c8) has joined #beagle
  • [16:13:08] * lardman is now known as lardman|gone
  • [16:28:19] * Noodlean (n=emil@foolean.ros.sgsnet.se) Quit (Remote closed the connection)
  • [16:28:46] <koen> likewise: do you know a place where I can get those brass 'busjes' to lift dev-board from the ground?
  • [16:34:02] <likewise> koen: yes, I know Farnell has them. How many do you need?
  • [16:34:40] <likewise> koen: they're called stand-offs if I am not mistaken. They come in white plastic as well.
  • [16:44:49] <dirk2> A lot of Google wiki updates in last hours: http://code.google.com/p/beagleboard/w/list
  • [16:47:17] <koen> likewise: I used to get them for free from a local computer store, they usually had tons left
  • [16:48:10] <koen> the shop has been closed for a few years now :(
  • [16:48:59] * koen wished devboard had a size standard so they could be stacked
  • [16:56:46] <likewise> koen: if you order them by size, they can be stacked. believe me. :-)
  • [16:57:06] <likewise> koen: it won't make for a pretty picture though
  • [16:57:35] <koen> :)
  • [17:26:41] <keesj> you might aswell hang them like art on the wall
  • [17:27:18] <koen> that's a bit too 70's for me
  • [17:27:19] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [17:28:56] <dirk2> khasim: hi
  • [17:29:01] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has left #beagle
  • [17:33:49] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has joined #beagle
  • [17:36:47] <dirk2> khasim: It seems to me that at http://code.google.com/p/beagleboard/wiki/BeagleSourceCode in section "Source for Beagle Board" behind the link "u-boot 1.3.3" there is still the old u-boot-beagle-rev2-trial2.tar.gz which is an old 1.1.4
  • [17:37:53] <dirk2> I didn't try the uboot binaries from that page if they are 1.1.4 or new 1.3.3 yet
  • [17:40:03] <sakoman__> khasim: any estimate on when the EVM u-boot 1.3.3 patch submission from your colleague will be ready?
  • [17:40:26] <sakoman__> I'm looking forward to upgrading my EVM ;-)
  • [17:42:23] * dannyBlue (n=chatzill@213.22.170.117) has joined #beagle
  • [17:44:01] <banderson> sakoman: I think the problem I had with LL_DEBUG/uart3 wasn't the issue. I think the problem is that uImage boot halts under certain circumstances
  • [17:44:34] <sakoman__> banderson: interesting! do you understand why?
  • [17:44:39] <banderson> sakoman: Namely when the board gets into a funk only a hard reset will fix it.
  • [17:45:44] <banderson> sakoman: Not yet. I did find out more about it however. I assumed it would always halt on soft reset and always work on hard reset. That doesn't seem to be the case.
  • [17:47:00] <banderson> But just to be clear I do think that what I am seeing now is what was causeing my problems before. Just without the benifit of debug out uart3 I had know idea that uImage was even booting
  • [17:47:16] <banderson> s/know/no
  • [17:47:28] <sakoman__> got it -- common root cause
  • [17:49:00] <koen> sakoman__: I get such symptons after uboot 1.3.x reports i2c errors, the kernel halts after "uncompressing......." (no debug_ll enabled)
  • [17:49:21] <banderson> sakoman: So on hard resets I am seeing a right around the twl4030 usb init or some other issue kernel fault or i2c erros
  • [17:49:42] <banderson> ...seeing issues that is...
  • [17:50:09] <banderson> once that happens only hard reset will fix. I can do 10+ soft resets and won't come out of it.
  • [17:50:29] <sakoman__> banderson: it would be really cool if you could find that spot! I have a feeling a numer of issues might go away then
  • [17:50:51] <banderson> Once I have a "good" boot then I can do a reset until I get some other i2c (twl4030) error
  • [17:51:17] <sakoman__> koen: I wonder which one of us has watched big buck bunny the most times this past week
  • [17:51:53] <sakoman__> I'm working on audio clicks during FF using mplayer and that clip
  • [17:52:18] <koen> I haven't watched it completely yet :)
  • [17:52:19] <banderson> sakoman: it does seem to be an init issue on one side. Souldn't act different on hard vs soft (in my opionion). The look as to why i2c has issues once in awhile. (could be same issue perhaps)
  • [17:53:25] <sakoman__> banderson: look for potential infinite loops -- I seem to recall seeing code that just loops on a hw bit
  • [17:54:08] <sakoman__> if the hw goes wonky that could explain the hang as well as the refusal to warm boot
  • [17:54:28] <koen> I pretty much only do warm boots on beagle
  • [17:55:01] <sakoman__> koen: I do the same on evm, just issue a reboot command in linux
  • [17:55:27] <koen> sysrq-b most of the time
  • [17:55:58] <sakoman__> banderson: another thought -- the evm hangs on boot if there is an mmc card in the slot. maybe related in some way?
  • [18:00:14] <banderson> sakoman: I was wondering about that when I fist started playing with evm. Thought it was another one of those problem that only I have...:)
  • [18:01:17] <banderson> sakoman: I am assuming that is not the case for the beagleboard? If not then is there differences in this area between beagle and evm
  • [18:02:51] * docelic_ is now known as docelic
  • [18:04:39] * dante (n=rdante@static-71-248-116-186.bltmmd.east.verizon.net) Quit ("Leaving")
  • [18:07:35] <koen> sakoman__: did you try the overlay on the evm yet?
  • [18:09:08] * dirk2 (n=dirk@F30e9.f.strato-dslnet.de) has left #beagle
  • [18:18:49] * BThompson (n=BThompso@nat/ti/x-c3655612676bd071) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [18:19:04] * BThompson (n=BThompso@nat/ti/x-25e8e0afcbc85fe3) has joined #beagle
  • [18:20:01] * docelic (n=docelic@78.134.194.163) Quit ("http://www.spinlocksolutions.com/")
  • [18:26:40] <sakoman__> koen: no, not yet. don't want to get distracted!
  • [18:27:02] <koen> :)
  • [18:27:16] <sakoman__> banderson: beagle seems to be fine with mmc inserted @ boot
  • [18:27:22] * jkridner|work1 (n=a0321898@nat/ti/x-68f78a11edec7e23) Quit ("Leaving.")
  • [18:27:43] <ds2> sakoman: what uboot on evm?
  • [18:27:59] <sakoman__> 1.1.4
  • [18:28:04] <ds2> i see the same thing
  • [18:28:14] <ds2> what build?
  • [18:28:38] <sakoman__> U-Boot 1.1.4 (Mar 7 2008 - 16:57:15)
  • [18:28:54] <jkridner> I believe EVM hanging on boot if a card is in the slot was a x-load or u-boot issue and is resolved in newer releases.
  • [18:29:12] <ds2> define newer
  • [18:29:24] <ds2> after July?
  • [18:29:32] <jkridner> I believe it was fixed in 0.9.7.
  • [18:29:48] <ds2> i see it in 0.9.8
  • [18:29:53] <ds2> =)
  • [18:29:55] <jkridner> please check the release notes at http://www.ti.com/omapsoftwareupdates
  • [18:30:09] <koen> http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20080710005104&newsLang=en
  • [18:30:11] <jkridner> did you completely reflash the OneNAND/NAND?
  • [18:30:12] <koen> beagle toy :)
  • [18:30:23] <ds2> a birdie made the same claim
  • [18:30:36] <ds2> yes both xloader and uboot
  • [18:32:27] <jkridner> hmmm... you might also post the issue for some attention at http://community.ti.com.
  • [18:32:41] <jkridner> I'll try to round up those in the know. That was a known issue a long time ago.
  • [18:33:03] <mru> good evening
  • [18:33:05] <ds2> i have via my channel
  • [18:33:41] <ds2> i need try newer build for them
  • [18:34:04] <ds2> <--- on a poor qual. bt kb
  • [18:34:34] <mru> koen: are you here?
  • [18:34:50] <sakoman__> I'll try the newer build too. I've been hesitating because the evm has been my most reliable omap3 platform and I hate to take the chance of breaking it!
  • [18:36:15] <ds2> SDP is better ;)
  • [18:37:21] <koen> mru: I'm here
  • [18:37:32] <koen> mru: 2007q3 doesn't get me the image corruption
  • [18:37:39] <koen> I just tested it a minute ago
  • [18:38:42] <khasim> ds2: The issue with MMC card boot on EVM is due to some issue in u-boot code
  • [18:39:08] <ds2> *nod*
  • [18:39:24] <khasim> in u-boot/board/omap3evm/sys_info.c
  • [18:39:32] <khasim> do the following change
  • [18:39:33] <khasim> u32 get_board_type(void) { ?????????????????????? if(get_cpu_rev() == (CPU_3430_ES2-1)) ?????????????????????????????????????????????? return OMAP3EVM_V2; ?????????????????????? else ?????????????????????????????????????????????? return OMAP3EVM_V1; }
  • [18:39:56] <khasim> if(get_cpu_rev() == (CPU_3430_ES2-1)) ????
  • [18:40:06] <khasim> this will make the board boot
  • [18:40:13] <ds2> trying to avoid a tangent debugging
  • [18:40:30] <khasim> with MMC/SD inside the slot
  • [18:40:40] <ds2> I will note that. thanks
  • [18:42:35] <ds2> real keyboard, much better now
  • [18:47:45] * macneib (n=macneib@76-10-128-118.dsl.teksavvy.com) has joined #beagle
  • [18:50:40] <KeyserSoze> i don't see a part number for the micron POP memory used on the beagle
  • [18:51:09] <KeyserSoze> is it purchased as a unit with the OMAP, or can a fab house use ordinary SMT techniques to attach it to the OMAP?
  • [18:54:06] <BThompson> if you buy the chips themselves they do not come with the POP memory attached, that is something your fab house will have to handle
  • [18:54:58] <BThompson> it seems the POP memory is not widely available, at least not advertised on the memory manufacturers websites (Micron or Samsung as I have seen), so you will have to contact them and possibly get a NDA to get further info on them
  • [18:56:04] <BThompson> eventually there will be chips available in a wider ball pitch that are cheaper/easier to manufacture and do not use the PoP memory, so if the PoP seems daunting you should be able to avoid it all together with the newer OMAP35xx packages
  • [18:56:58] <KeyserSoze> ideally, i'd like to buy the omap3 and memory together as a unit. although perhaps i should talk to the board house and see if assembling the PoP is a big deal or not
  • [18:57:11] <ds2> isn't POP somewhat unique in that it has both SDRAM and Flash?
  • [18:57:53] <KeyserSoze> the fact that it's attached to the top of a BGA microcontroller makes it unique enough, the two types of memory notwithstanding :D
  • [18:58:37] <KeyserSoze> the only part I've ever used that was similar was a ATI radeon MCM (Multi-chip module), but in that case the GPU and memory were next to each other on top of the same package.
  • [18:58:48] <ds2> maybe I am greedy but It would nice to have a stack of: TWL4030:OMAP3:Memory
  • [18:58:55] <KeyserSoze> stacking them up saves tons of space and also means i don't need to route high-speed signals on my board
  • [19:00:37] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [19:03:53] <koen> I suspect the gcc 4.3 ffmpeg bug is the same as the kernel one
  • [19:04:04] <koen> related to the pld instruction
  • [19:07:53] * RogerMonk (n=a0740758@nat/ti/x-b9e375c20318d3c8) Quit (Remote closed the connection)
  • [19:09:07] * travisutk (n=travis@mil.engr.utk.edu) Quit ("Leaving")
  • [19:09:08] <mru> I don't think so
  • [19:09:17] <mru> ffmpeg doesn't use pld in that way
  • [19:10:13] <mru> so csl2007q3 compiles ffmpeg ok?
  • [19:11:03] <koen> it seems to
  • [19:11:44] <mru> I lost a lot of confidence in gcc with 4.3
  • [19:11:56] <mru> whatever was left after 4.2, that is
  • [19:12:23] <koen> I don't have a lot of confidence in csl either
  • [19:12:31] <koen> I use what produces working binaries
  • [19:12:51] <koen> and it seems that for everything minus kernel,ffmpeg gcc 4.3 is the thing to use
  • [19:13:04] <koen> unless you want to vet CFLAGS for every package
  • [19:14:59] <ds2> it can't be as bad as gcc 2.95
  • [19:15:01] * dannyBlue (n=chatzill@213.22.170.117) Quit ("ChatZilla 0.9.83 [Firefox 3.0/2008052906]")
  • [19:15:06] <ds2> can it?
  • [19:15:09] <koen> 2.96!
  • [19:15:37] <koen> ds2: there are still people claiming gcc 2.95.3 is the best thing since sliced bread
  • [19:16:06] <ds2> and there are still linux kernels that will only compile in that ;)
  • [19:17:10] <mru> some idiot decided that a particular mips stb at work was to use gcc 2.96
  • [19:17:17] <koen> ds2: there's a whole batch of software that needs to be compiled with gcc 2.95.3 to avoid races....
  • [19:17:27] <koen> mru: there is no gcc 2.96 :)
  • [19:17:36] <mru> officially, no
  • [19:18:24] <mru> iirc, redhat took 2.95, broke it in a variety of ways, and called it 2.96
  • [19:18:52] <mru> and it's causing no end of trouble
  • [19:19:40] <koen> right
  • [19:19:48] <mru> we use about half a dozen gcc versions at work
  • [19:19:54] <mru> each has its own bugs
  • [19:22:01] <koen> I'm down to 4.1.1 (ppc405) 4.2.2 (avr32), 4.2.4 (the rest), 4.3.1 (armv7) and 2007q3 for armv7 kernels
  • [19:22:21] <koen> I will gain a new one if I decide to try blackfin again
  • [19:22:49] <ds2> does the blackfin have a MMU?
  • [19:22:50] <mru> for example, some gcc versions miscompile this: double d; ... unsigned u = d > 0? (unsigned)d: (unsigned)(int)d;
  • [19:23:02] <koen> ds2: no
  • [19:24:07] <mru> and thank mozilla for the need for that expression in the first place
  • [19:24:47] * jkridner|work (n=a0321898@nat/ti/x-c64eaf0017d3929f) has joined #beagle
  • [19:25:50] <koen> I usually only blame mozilla
  • [19:26:35] <ds2> what does (unsigned)(int)d do?
  • [19:27:11] <ds2> is it something like abs((int)d) with a floor/ceil at MAX_INT?
  • [19:27:23] <mru> no
  • [19:27:44] <mru> it converts d to int, then converts the int to unsigned
  • [19:28:16] <ds2> assuming 32bit ints; if d is 2^31+2, what is the result?
  • [19:28:25] <mru> undefined
  • [19:28:31] <ds2> okay
  • [19:28:47] <mru> and I've seen several different results
  • [19:29:03] <ds2> okay, what about if d is -1?
  • [19:29:18] <mru> converting to int is fine
  • [19:29:25] <mru> converting to unsigned is undefined
  • [19:29:30] <mru> hence the nasty expression
  • [19:29:35] <ds2> ah gotcha
  • [19:29:49] <ds2> thought it would return something like 0xfffffffe
  • [19:29:58] <mru> some implementations do
  • [19:30:01] <mru> some return 0
  • [19:30:02] <ds2> great
  • [19:30:20] <mru> er.. I'm confused
  • [19:30:33] <ds2> oops
  • [19:30:41] <ds2> 0xffff ffff I think is what i was trying to say
  • [19:30:56] <mru> 2's complement -1
  • [19:31:30] <mru> similarly, for positive overflow, some implementations wrap, some clamp at INT_MAX
  • [19:35:20] <mru> btw, did you read about the evil cmov "optimisation" gcc was doing on x86?
  • [19:37:06] <koen> I vaguely recall something about it
  • [19:37:44] <mru> iirc, it would load a memory word to a register, conditionally alter the register, then unconditionally store it back
  • [19:38:28] <mru> imagine that condition being the return value of pthread_mutex_trylock()
  • [19:39:44] <mru> but that still doesn't beat the bug I found in a green hills compiler recently
  • [19:41:22] <mru> koen: any idea why gcc 4.3 miscompiles ffmpeg?
  • [19:41:37] <koen> mru: nope
  • [19:42:49] <koen> it started doing it 'halfway' your neon commits
  • [19:43:07] <koen> I'm a bit too lazy now to track down the commit that triggers it
  • [19:43:11] <mru> very odd
  • [19:43:22] <mru> the neon stuff is all written in assembler
  • [19:51:46] * Noodlean (n=emil@foolean.ros.sgsnet.se) has joined #beagle
  • [19:52:45] <mru> koen: perhaps it takes less time to disable some of the neon functions, and see which one is the offender
  • [19:54:22] <mru> my guess would be that it's one of the put_pixels* functions
  • [19:58:35] <mru> there's 16 of them, so a binary search should pinpoint it pretty quickly
  • [19:58:46] <koen> right
  • [19:58:54] <koen> I can try that over the weekend
  • [19:59:25] * ali_as_ (n=ali_as@ambix.plus.com) Quit ("Router reboot.")
  • [20:02:23] * ali_as (n=ali_as@ambix.plus.com) has joined #beagle
  • [20:05:31] <mru> hey, I think I've found it
  • [20:16:41] <koen> mru: yes?
  • [20:17:03] <mru> slightly wrong inline assembler operand constraints
  • [20:17:19] <mru> gcc 4.3 chose to use the same register for several operands
  • [20:17:22] <mru> great...
  • [20:17:58] <mru> I committed what I think is a fix
  • [20:18:19] <keesj> What would be a good place to start reading about the CortexT-A8 and neno
  • [20:18:23] <mru> output of gcc -S looks good
  • [20:18:27] <keesj> neon
  • [20:18:44] <mru> keesj: the reference manual would be great, but it seems impossible to get
  • [20:19:41] <koen> mru: ok, great! I'll test that tomorrow
  • [20:19:54] <mru> keesj: http://infocenter.arm.com/ has some stuff
  • [20:20:44] <mru> http://infocenter.arm.com/help/topic/com.arm.doc.dui0204h/Bcfjicfj.html has something about neon
  • [20:20:54] <mru> it's a bit brief, but better than nothing
  • [20:21:12] <mru> you'll easily find the cortex-a8 trm on the same site
  • [20:22:26] <mru> unfortunately there isn't one for r1p2 posted
  • [20:23:49] <keesj> r1p2?
  • [20:24:35] <mru> versions of the silicon
  • [20:25:17] <keesj> ok
  • [20:25:41] <mru> I don't know what the differences are
  • [20:25:50] <mru> but apparenly the errata for r1p1 is scary reading
  • [20:26:07] <mru> omap3530 uses r1p2
  • [20:26:18] <mru> contrary to what its manual states
  • [20:27:06] <keesj> I am mainly interested in it for my jtag thingy, I want to know what it is that I am trying :p
  • [20:28:29] <mru> then you'll certainly want the omap3430 trm
  • [20:30:25] <mru> which is again tricky to find
  • [20:33:02] <mru> the link to the TI website seems dead
  • [20:38:15] <mru> jkridner or other TI people: are you seeing this?
  • [20:49:28] <keesj> I downloaded the cortex-a8 trm from arm.com that sounds like what I am searching for right?
  • [20:49:40] <mru> that describes the arm core
  • [20:49:59] <mru> external interfaces like jtag are described in the omap trm
  • [20:50:19] <keesj> bugger :p
  • [20:50:20] <mru> the jtag also accesses the dsp
  • [20:51:52] <keesj> thanks a lot
  • [20:52:26] <BThompson> the 3530 TRM is up seems like http://focus.ti.com/lit/ug/spruf98a/spruf98a.pdf
  • [20:57:11] <keesj> Cool that can keep me bussy for a while !
  • [20:59:55] <mru> there was something missing in the 3530 manual, but now I can't remember what it was
  • [21:01:06] <BThompson> there should not be anything missing from the 3530 manual that you would be using typically
  • [21:01:32] <mru> I'm not a typical person
  • [21:01:46] <BThompson> what are you making? :)
  • [21:04:00] <banderson> cookies!!?!?! Thats what every good manual needs is a cookie recipe!!
  • [21:04:09] <mru> emacs has one
  • [21:15:55] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has left #beagle
  • [21:20:55] * BThompson (n=BThompso@nat/ti/x-25e8e0afcbc85fe3) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [21:21:32] * Olipro_ (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [21:22:24] * Olipro (i=Olipro@unaffiliated/olipro) Quit (Nick collision from services.)
  • [21:22:26] * Olipro_ is now known as Olipro
  • [21:41:45] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has joined #beagle
  • [21:42:37] * likewise (n=chatzill@82-171-51-231.ip.telfort.nl) Quit ("ChatZilla 0.9.83 [Firefox 3.0/2008061015]")
  • [21:55:28] * dannyBlue (n=chatzill@213.22.170.117) has joined #beagle
  • [21:58:54] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) Quit ("Leaving.")
  • [22:04:34] * RobotGuy is now known as RobotGuy-Out
  • [22:07:36] * Noodlean (n=emil@foolean.ros.sgsnet.se) Quit (Remote closed the connection)
  • [22:07:37] * dannyBlue (n=chatzill@213.22.170.117) Quit ("ChatZilla 0.9.83 [Firefox 3.0/2008052906]")
  • [22:16:01] * bazbell (n=a0192809@nat/ti/x-de3fc05950409632) Quit (Remote closed the connection)
  • [22:17:31] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [22:18:46] * prpplague (n=dave@mail.americanmicrosystems.com) Quit ("Leaving")
  • [23:00:34] * jkridner|work (n=a0321898@nat/ti/x-c64eaf0017d3929f) Quit ("Leaving.")
  • [23:03:51] * intu (n=intu@ubr1-201-91.ubr.tartu.stv.ee) Quit ("Leaving.")
  • [23:09:57] <banderson> sakoman: Found out where uImage boot hangs at...
  • [23:10:04] * RobotGuy-Out is now known as RobotGuy
  • [23:10:10] <sakoman__> do tell!
  • [23:10:27] <banderson> sakoman: i2c-omap.c
  • [23:10:48] <sakoman__> somehow that doesn't surprise me
  • [23:11:08] <banderson> hmmm don't know if that should up well
  • [23:11:40] <sakoman__> ?
  • [23:12:44] <banderson> http://pastebin.com/m4a32f8c0
  • [23:13:14] <banderson> sorry tried to put code in irc ...don't think it worked so I put it in link above
  • [23:15:18] <sakoman__> ah the old infinite loop waiting on a hw bit bug
  • [23:16:21] <sakoman__> did you try fixing it to fall out of the loop after more than "a couple of loops max"?
  • [23:17:15] <sakoman__> I wonder if the general i2c flakiness is related to this kind of thing
  • [23:31:46] * banderson (n=irc@69.71.183.7) Quit (Read error: 110 (Connection timed out))
  • [23:33:43] * bazbell (n=a0192809@nat/ti/x-064af9d56c791db9) has joined #beagle
  • [23:36:51] * banderson (n=irc@69-71-183-7.mammothnetworks.com) has joined #beagle
  • [23:37:46] <banderson> Just lost power to building. I have to try to get evm in same funk state then edit code and see.
  • [23:38:57] <banderson> It is supprising how stable something is when you *want* it to fail....
  • [23:39:54] <mru> I was showing off the beagle at work today, and of course it had to crash...
  • [23:42:03] <banderson> Well this is it for me this week ...(going camping) will start at it again on monday...
  • [23:44:34] * Olipro_ (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [23:45:46] * Olipro (i=Olipro@unaffiliated/olipro) Quit (Nick collision from services.)
  • [23:45:50] * Olipro_ is now known as Olipro
  • [23:46:48] * banderson (n=irc@69-71-183-7.mammothnetworks.com) Quit ("Leaving")