• [00:56:53] * bazbel1 (n=a0192809@nat/ti/x-372e480e4b6ae0a9) has joined #beagle
  • [01:00:52] * bazbell (n=a0192809@nat/ti/x-200b3608f0d579ae) Quit (Remote closed the connection)
  • [01:35:00] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [01:37:56] * rsalveti_ (n=salveti@189.70.140.74) has joined #beagle
  • [01:38:23] * rsalveti (n=salveti@189.70.140.74) Quit (Read error: 104 (Connection reset by peer))
  • [03:20:24] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [03:28:14] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [03:39:31] * bazbel1 (n=a0192809@nat/ti/x-372e480e4b6ae0a9) Quit ("Leaving.")
  • [05:56:21] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [06:50:03] * trickie (n=trickie@basesoft.xs4all.nl) has joined #beagle
  • [06:58:24] <koen> good morning all
  • [07:53:17] <jkridner> good morning
  • [07:53:29] * BeagleLogBot2 (n=PircBot@ec2-75-101-156-174.compute-1.amazonaws.com) Quit (Remote closed the connection)
  • [07:54:17] * BeagleLogBot2 (n=PircBot@ec2-75-101-156-174.compute-1.amazonaws.com) has joined #beagle
  • [08:19:51] <koen> jkridner: up early or up late?
  • [08:32:08] * royerfa (n=x0091539@nat/ti/x-0720ff96f422137e) has joined #beagle
  • [08:43:43] * DJWillis (n=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) Quit ("Manny: It's my scythe. I like to keep it next to where my heart used to be.")
  • [08:48:50] * royerfa (n=x0091539@nat/ti/x-0720ff96f422137e) Quit (Remote closed the connection)
  • [08:58:50] * esden is now known as esden`away
  • [09:06:23] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [09:07:05] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [09:24:45] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [09:30:34] * lardman|gone is now known as lardman
  • [09:34:17] * royerfa (n=x0091539@nat/ti/x-2638b3635e12e10d) has joined #beagle
  • [10:25:57] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [10:30:42] * rsalveti_ (n=salveti@189.70.140.74) Quit (Read error: 110 (Connection timed out))
  • [11:10:35] * koen reads http://gcc.gnu.org/gcc-4.3/porting_to.html again
  • [11:22:58] <Crofton|work> http://www.cnn.com/2008/US/07/14/anheuser.inbev.ap/index.html
  • [11:23:18] <Crofton|work> damn foreigners are buying everything
  • [11:30:31] <Crofton> hmm, this u-boot has i2c timeouts/
  • [11:34:16] <Crofton|work> where are we keeping the "best" MLO/u-boot images?
  • [11:35:12] <Crofton|work> koen, how can I build an image that uses the old libusb?
  • [11:37:07] * DJWillis (n=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) has joined #beagle
  • [11:38:25] <DJWillis> koen: about? Is the OE patchset still the latest and greatest for the Beagle?
  • [11:39:46] * Crofton|work can't wait for Tony to get back from vacation and get caught up with the kernel pathces
  • [11:41:17] <DJWillis> Crofton: Yep, I am trying to clean up the Pandora stuff to push for RFC but the snag is that I have a lot of patch on patch on patch so getting the backlog in would be great.
  • [11:42:58] <koen> Crofton|work: if you get i2c timeouts in uboot -> powercycle
  • [11:43:13] <koen> Crofton|work: disable the libusb1 and libusbcompat recipes
  • [11:44:12] * RogerMonk (n=a0740758@nat/ti/x-a9f7b06505d9a5f4) has joined #beagle
  • [11:44:23] <koen> DJWillis: the kernel patches in OE are still the latest and greatest
  • [11:44:56] <DJWillis> koen: great, borrowing some of them so wanted to check ;-)
  • [11:45:18] <Crofton|work> def_pre = -1?
  • [11:45:24] <Crofton|work> or BBMASK?
  • [11:45:29] <koen> Crofton|work: I'm waiting for a new patch series for the cpuidle stuff
  • [11:45:43] <koen> Crofton|work: just delete them during your test build
  • [11:45:51] <Crofton|work> ok
  • [11:45:58] <koen> Crofton|work: and remove libusb* from deploy/ipk
  • [11:45:59] <Crofton|work> I want to try against the older stuff
  • [11:46:24] <DJWillis> koen: should I still be using MTN for oe.dev?
  • [11:46:24] <Crofton|work> will there be any DEPENDS issues?
  • [11:47:24] <koen> you can use git if you dont plan on getting commit access the next few weeks
  • [11:47:43] <koen> Crofton|work: if there are depends issues, they should be easy to fix
  • [11:48:47] * mib_7wdz6w (i=7aa60de8@gateway/web/ajax/mibbit.com/x-b0177d7196b49ccc) has joined #beagle
  • [11:49:07] <Crofton|work> I get transfer errors as soon as I start moving data from the usrp
  • [11:52:08] <DJWillis> koen: if they are both in sync i'll stick with MTN then as it works 'tm' and enough things seem to have broken as it is.
  • [11:57:49] <koen> mtn is still the master repo
  • [11:59:05] * bazbell (n=a0192809@nat/ti/x-0725ef1ab6e66507) has joined #beagle
  • [12:00:44] * rsalveti (n=salveti@200.184.118.132) has joined #beagle
  • [12:04:30] * mib_7wdz6w (i=7aa60de8@gateway/web/ajax/mibbit.com/x-b0177d7196b49ccc) Quit ("http://www.mibbit.com ajax IRC Client")
  • [12:06:24] <Crofton> does anyone know anything about the yahoo omap group?
  • [12:07:27] <Crofton> grr members only
  • [12:13:32] <Crofton> and full of spam
  • [12:15:16] <Crofton> RogerMonk, ping
  • [12:15:22] <RogerMonk> pong pong pong
  • [12:15:29] <Crofton> hey
  • [12:15:36] <Crofton> https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/index.html
  • [12:15:42] <RogerMonk> yep
  • [12:15:46] <Crofton> I'm working through the linux dsp tool install
  • [12:15:58] <Crofton> this link refers to an OMAP yahoo group
  • [12:16:05] <Crofton> that is full of p0rn spam
  • [12:16:12] <RogerMonk> hmmm
  • [12:16:23] <RogerMonk> I wouldn't worry about that group
  • [12:16:28] <RogerMonk> we'll get the page updated
  • [12:16:35] <Crofton> you may want to pass that info to the "people in charge"
  • [12:16:42] <Crofton> yeah
  • [12:16:46] <RogerMonk> This used to be used in the old 54x linux tools days on omap1510
  • [12:16:52] <Crofton> ah
  • [12:16:53] <RogerMonk> (sorry - 5912 - catalog version)
  • [12:17:03] <Crofton> yeah
  • [12:17:14] * koen has a 1710 gathering dust
  • [12:17:32] * Crofton has access to the OSK
  • [12:21:35] <koen> sometimes I think there should be a library for devboard
  • [12:21:49] <koen> need to test something, check it out for a week and return it
  • [12:22:21] <Crofton> RogerMonk, also you download a .bin file, but the readme has no install instructions
  • [12:22:38] <DJWillis> koen: Great idea :D, put a deposit down, check it out, send it back.
  • [12:23:00] <koen> DJWillis: I have run out of deskspace :(
  • [12:23:06] <DJWillis> lol
  • [12:23:32] <koen> I've resorted to bringing the devboard I'm working on to the living room
  • [12:23:59] <DJWillis> Hmm, I tend to do that anyway. I ran out of space years ago
  • [12:26:04] * BThompson (n=BThompso@nat/ti/x-078e0a3383a04761) has joined #beagle
  • [12:28:39] <Crofton> hmmm it is a 386 executable
  • [12:28:57] <koen> Crofton|work: yeah, I noticed that as well
  • [12:29:35] <Crofton> btw, Happy Bastille Day to the French here
  • [12:32:54] * ldesnogu2 (n=ldesnogu@ven06-2-82-247-86-183.fbx.proxad.net) has joined #beagle
  • [12:35:39] <Crofton> this is quite the racket, pretending to be injured so you can ahng on the doctors car ...
  • [12:54:57] <Crofton> where is the dspbios library?
  • [12:55:05] <RogerMonk> ?
  • [12:55:06] * GeneralAntilles (n=GeneralA@c-69-244-211-19.hsd1.fl.comcast.net) has joined #beagle
  • [12:56:12] <Crofton> I'm poking around the dsp tools
  • [12:56:28] <RogerMonk> yep, that's just the compiler / toolchain
  • [12:56:30] <Crofton> my understanding is that dsplink needs dspbios
  • [12:56:46] * BThompson (n=BThompso@nat/ti/x-078e0a3383a04761) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [12:56:53] <RogerMonk> yep, that's not available to all right now... you'll need to grab it from the target content web on www.ti.com
  • [12:57:11] * BThompson (n=BThompso@nat/ti/x-abdcfeaf37f6036e) has joined #beagle
  • [12:57:18] <Crofton> is there a link?
  • [12:57:30] <RogerMonk> I'll send u an email
  • [12:57:34] <Crofton> thanks
  • [12:58:21] <koen> RogerMonk: do you have sd cards to go with the demo beagles?
  • [12:58:40] <RogerMonk> Koen - I have a couple - how big?
  • [12:59:33] <koen> 512MB should be enough for desktop-demos, bigger for the video demo
  • [12:59:42] <koen> 720p video takes a lot of space...
  • [13:00:07] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has joined #beagle
  • [13:00:20] <koen> I have one SD card ready now, I suspect mru has one read as well
  • [13:00:33] <koen> RogerMonk: did khasim prepare any 3d demos?
  • [13:05:24] <RogerMonk> Koen - yes
  • [13:05:37] <RogerMonk> waiting for a new beagle to test though... mine is too unstable
  • [13:08:31] <koen> my beagle has become more stable lately
  • [13:08:42] <koen> but I really want new cpuidle patches
  • [13:09:49] <RogerMonk> more stable?
  • [13:10:04] <koen> it doesn't freeze after 20 minutes
  • [13:10:40] <RogerMonk> do you have an OE recipe that pulls in mrus stuff now that I should get building?
  • [13:10:58] <koen> you mean his ffmpeg stuff?
  • [13:11:03] <RogerMonk> yep
  • [13:11:25] <koen> bitbake omapfbplay' will get a static binary of the player and 'bitbake ffmpeg' a shared lib version of ffmpeg
  • [13:12:26] <koen> RogerMonk: could you put the 3d stuff on ftp and mail me the link?
  • [13:12:53] <RogerMonk> Koen - ok
  • [13:13:11] * koen heads to a meeting
  • [13:13:13] <RogerMonk> Koen - it runs on 0.9.8 kernel though
  • [13:13:23] <koen> jkridner|work: I'm still working on the quote
  • [13:13:45] * RogerMonk heads out..
  • [13:13:52] <jkridner> thanks. I think that Helen mentioned what the deadline is.
  • [13:13:55] <koen> RogerMonk: yeah, khasim mentioned that he couldn't keep up with the 'one rc every week' for omap git
  • [13:14:35] <koen> ah, sweet
  • [13:14:35] <koen> http://kerneltrap.org/mailarchive/linux-kernel/2008/7/13/2450154
  • [13:14:37] <koen> 2.6.26
  • [13:14:39] <RogerMonk> Koen - yep - can we move the beagle-demo to 0.9.8 kernel so that everything runs in the same image
  • [13:14:43] <RogerMonk> ?
  • [13:15:03] <koen> RogerMonk: we could for the 3d demo
  • [13:15:12] <koen> RogerMonk: its jsut a amtter of replacing the uImage
  • [13:15:40] <RogerMonk> Koen - yep, it would be nice to run the whole thing (desktop+mplayer+3d) though all together...
  • [13:16:10] * koen heads out
  • [13:25:26] * RogerMonk (n=a0740758@nat/ti/x-a9f7b06505d9a5f4) Quit (Remote closed the connection)
  • [13:35:57] * prpplague (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [14:05:51] <Crofton> hmmm, Who is the "Brian Cruikshank" person?
  • [14:06:12] <Crofton> I know one, but he is more of an ASIC guy these days according to linked in
  • [14:16:12] * RogerMonk (n=a0740758@nat/ti/x-a5eb95af76e50f7f) has joined #beagle
  • [14:19:16] * docelic (n=docelic@78.134.193.128) has joined #beagle
  • [15:01:57] * RogerMonk (n=a0740758@nat/ti/x-a5eb95af76e50f7f) Quit (Remote closed the connection)
  • [15:02:15] * RogerMonk (n=a0740758@nat/ti/x-d1a3e4b5fff12330) has joined #beagle
  • [15:02:44] * Olipro_ (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [15:03:27] * Olipro (i=Olipro@unaffiliated/olipro) Quit (Nick collision from services.)
  • [15:03:29] * Olipro_ is now known as Olipro
  • [15:05:32] <jkridner> Brian is a TI guy.
  • [15:05:58] <jkridner> I believe he is based in Toronto.
  • [15:07:40] * banderson (n=irc@69.71.183.7) has joined #beagle
  • [15:08:03] <jkridner> not the same guy as the one at STMicro.
  • [15:08:08] * lardman is now known as lardman|gone
  • [15:08:23] <prpplague> greetings earthlings
  • [15:09:03] <prpplague> jkridner: how goes the dev? there are something like 15+ omap related jobs postings in the DFW area this month
  • [15:09:23] * JoeBorn__ is now known as JoeBorn
  • [15:09:29] <prpplague> jkridner: looks like alot of companies are planning products with the new omaps
  • [15:09:34] <jkridner> :)
  • [15:10:00] <jkridner> that's good news for the people hanging out here leveraging their experience.
  • [15:10:30] <jkridner> which part of the dev?
  • [15:10:39] <jkridner> the development is moving along many different fronts.
  • [15:11:02] <prpplague> jkridner: generic question, more like dev==battle
  • [15:11:20] * royerfa (n=x0091539@nat/ti/x-2638b3635e12e10d) has left #beagle
  • [15:11:24] <Crofton> jkridner, the one I know is in CO
  • [15:11:47] <jkridner> It is getting a bit chaotic for me, but in a good way.
  • [15:12:23] <prpplague> ahh
  • [15:19:20] <docelic> Hey folks, should at least theoretically a "Memory Stick Pro Duo" work in the sd/mmc slot on the board?
  • [15:19:30] <docelic> I didn't find a note about it in the hardware manual
  • [15:23:05] <docelic> hm looks like not, there's small difference in the pin slots when you put it in
  • [15:23:24] <docelic> btw thanks, my board arrived today, I'll post the shippment id to the list later today
  • [15:24:40] * dirk2 (n=dirk@F33b3.f.strato-dslnet.de) has joined #beagle
  • [15:28:40] <prpplague> docelic: iirc the sony memory stick pro duo is not compatible with any of the sd/mmc specs either on the hardware or software side
  • [15:32:38] <docelic> prpplague, yep. I once bought it by mistake (I needed MS Pro, not Pro Duo), and I still haven't been able to find anything that I have where it'd fit in
  • [15:33:20] <prpplague> docelic: about the only thing you are going to find to use it with is going to be a sony digital camera
  • [15:43:12] <dirk2> kernel hang after some time, issue #22: Anybody here already tried http://marc.info/?l=linux-omap&m=121604209723787&w=2 ? Seems to work Anand :)
  • [15:44:11] <dirk2> s/work Anand/work for Anand/
  • [15:50:20] <sakoman__> dirk2: I haven't tried it on beagle, but since I don't see this issue on the evm it adds further eveidence to Anand's theory that it might be related to the Beagle's use of ttys2 (EVM uses ttys0)
  • [15:53:41] <dirk2> sakoman__: I even don't understand what this code does and why the code might be ttyX related ;)
  • [15:55:06] <sakoman__> dirk2: well, that's one of the reasons I haven't tried it! I like to understand patches before I apply them
  • [15:55:27] <sakoman__> Just haven't had the time to dig into it. To do list is far too long these days
  • [15:59:25] <koen> sakoman__: I'm waiting for new cpuidle patches, they are supposed to fix uart issues as well
  • [16:00:25] <sakoman__> koen: who is doing the cpuidle patches?
  • [16:00:48] <docelic> Ok I've tried the board with 2 power supplies, both are ~5V. On both, power led is on, but with one the other three leds are lit also, while with the other the three leds blink. Which behavior is correct?
  • [16:01:00] <koen> sakoman__: multiple people :(
  • [16:01:18] <koen> sakoman__: the latest ~30 mails on linux-omap are about it
  • [16:01:40] <koen> sakoman__: it's a combination of cpu-idle, pn-noop and suspend-workarounds
  • [16:01:49] <koen> atm all patches are interdependant
  • [16:03:58] <sakoman__> koen: ah, yes. I recall seeing that discussion. Didn't feel like they were close to consensus last time I looked
  • [16:05:11] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [16:06:22] <koen> sakoman__: some people encountered the 'interdependant' bit
  • [16:06:46] <koen> the latest mail has this bit: "Yes, I probably was using an older omap-pm-noop patch from Paul. "
  • [16:09:17] <sakoman__> koen: hopefully one person will step up and propose an integrated patch. Feels like to many chefs in the kitchen right now
  • [16:12:47] <koen> I think they are al waiting for tony to return :)
  • [16:14:25] <sakoman__> koen: have you found a reproducible way to get the asoc null pointer failure?
  • [16:14:34] <sakoman__> I can't get it to fail on the evm
  • [16:15:45] <koen> mplayer usually does it for me
  • [16:16:02] <dirk2> What do we have in queue for OMAP linux when Tony is back? NAND patch update, some of Mans' display patches, Kconfig display resoluiton?
  • [16:16:52] <koen> and ASoC
  • [16:17:21] <sakoman__> dirk2, koen: yes that looks like the list of stuff I have in my linux-omap git
  • [16:18:45] <sakoman__> koen: anything in particular trigger it with mplayer? I'm able to be pretty brutal with FF, RW commands and it seems to work flawlessly
  • [16:19:06] <koen> sakoman__: most of the time just starting mplayer triggers it
  • [16:19:46] <sakoman__> hmm . . . strange. are you using the mp4 version of the movie?
  • [16:19:56] <koen> yes
  • [16:20:44] <sakoman__> koen: Same here. OK, guess I might have to move back to beagleboard to reproduce this.
  • [16:21:17] <koen> to put it politely: you don't have try hard to reproduce it
  • [16:22:28] <sakoman__> koen: It is bizarre how different evm and beagleboard can be. I really hope to some day get to the bottom of what might be different.
  • [16:23:04] <koen> I saw a mention of 'older silicon on beagleboards'
  • [16:23:10] <sakoman__> perhaps
  • [16:23:20] <jkridner> Beagle and EVM both use ES2.1.
  • [16:23:33] <sakoman__> well, there goes that theory ;-)
  • [16:23:52] <koen> it might be that we all have broken silicon
  • [16:24:14] <sakoman__> the kernels I'm using for the 2 are practically identical
  • [16:24:58] <sakoman__> ah well, I'll give beagle a try
  • [16:25:01] <dirk2> but we have different ttysX which seems to be influenced by 'magic' code patches ;-)
  • [16:25:16] <koen> NOTE: Applying patch 'serialfix.diff' (/home/koen/OE/monotone/org.openembedded.dev/packages/linux/linux-omap2-git/beagleboard/serialfix.diff)
  • [16:34:59] <koen> RogerMonk: I got your dsp email, did you already send the sgx mail?
  • [16:50:35] * RogerMonk (n=a0740758@nat/ti/x-d1a3e4b5fff12330) Quit (Remote closed the connection)
  • [16:56:35] * tobor (n=tobor@unaffiliated/toborr) has joined #beagle
  • [17:00:43] * RogerMonk (n=a0740758@nat/ti/x-3b243775ca46f6a2) has joined #beagle
  • [17:10:39] <RogerMonk> Koen - nope - I've been in meetings all afternoon
  • [17:11:53] * koen just returned from meetings
  • [17:26:23] * jkridner|work (n=a0321898@nat/ti/x-895e5354c86af6b5) Quit ("Leaving.")
  • [17:28:12] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [17:30:55] * Olipro_ (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [17:49:04] * Olipro (i=Olipro@unaffiliated/olipro) Quit (Connection timed out)
  • [18:16:17] * jkridner|work (n=a0321898@nat/ti/x-6984fb637d169014) has joined #beagle
  • [18:16:25] * dirk2 (n=dirk@F33b3.f.strato-dslnet.de) has left #beagle
  • [18:26:26] * RogerMonk (n=a0740758@nat/ti/x-3b243775ca46f6a2) Quit (Remote closed the connection)
  • [18:45:55] * Crofton|work just returned from solving a problem caused by him being an idiot
  • [18:46:26] <mru> newsflash, Crofton|work is no longer an idiot
  • [18:46:42] <Crofton|work> heh
  • [18:46:59] <Crofton|work> I'm sure I will create many more bugs in time
  • [18:47:11] <Crofton|work> first set up the radio, then start data flowing
  • [18:47:15] <Crofton|work> not the other way around
  • [18:52:06] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [18:52:17] <koen> heh
  • [18:53:03] <koen> reminds me of the abiword-plugin 'fix' I did yesterday
  • [18:53:31] <koen> after 2 hours: "hmmm, why is that line labeled with '#this is a hack'?"
  • [18:53:55] <koen> removed line and it suddenly built without troubles
  • [18:53:58] <mru> if it says it's a hack, it usually is
  • [18:54:05] <mru> unless it's a kludge
  • [18:54:27] <koen> the worst part is that I added that hack 2 years ago :)
  • [18:54:29] * Olipro_ is now known as Olipro
  • [19:18:21] <Crofton|work> well, he really did do it
  • [19:18:24] <Crofton|work> http://ac360.blogs.cnn.com/2008/07/08/a-little-truth-a-big-break/
  • [19:18:25] <ds2> "The Beagle is equipped with a DVI-D connector that uses an HDMI connector that was selected for its small size." <----
  • [19:18:35] <ds2> not content, wording
  • [19:20:52] <ds2> Table 3 - "12.5" Mb/S? AFAIK, USB Full Speed is 12.0Mb/S
  • [19:21:23] <Crofton|work> is the OTG port high speed capable?
  • [19:21:30] <ds2> yes
  • [19:21:55] <ds2> clarify that... the MUSB controller and the TWL4030 can do full/high/low speed
  • [19:22:06] <ds2> donno if there are layout issues that will prevent it
  • [19:23:21] <koen> yes
  • [19:23:54] <koen> EHCI can only does high speed (480MBit/s), you need a hub for low and full speed (1.5 and 12Mbit/s)
  • [19:38:38] * docelic (n=docelic@78.134.193.128) Quit ("http://www.spinlocksolutions.com/")
  • [20:27:12] <j24> all: do you known when revb-request@beagleboard.org will answer?
  • [20:27:32] <Crofton|work> they will serve no board before its time
  • [20:27:53] <Crofton|work> I think someone said the other day they answer as boards become available
  • [20:29:09] * Crofton|work knows that is not a satisfying answer
  • [20:45:24] * ldesnogu2 (n=ldesnogu@ven06-2-82-247-86-183.fbx.proxad.net) Quit ()
  • [20:58:09] * bazbell (n=a0192809@nat/ti/x-0725ef1ab6e66507) Quit (Remote closed the connection)
  • [21:04:39] * hagisbasheruk (n=hagisbas@cpc4-clyd1-0-0-cust357.renf.cable.ntl.com) has joined #beagle
  • [21:22:19] * BThompson (n=BThompso@nat/ti/x-abdcfeaf37f6036e) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [21:23:29] <sakoman__> koen: when running mplayer on beagle I get sporadic failures. Most seem to be i2c related: transmit overflow, irq56: nobody cared while in the omap_i2c_idle routine, stuff like that
  • [21:24:32] <sakoman__> bizarre! don't see that on EVM -- just the one-time soft lockup.
  • [21:25:06] <sakoman__> and now: i2c_omap i2c_omap.1: controller timed out
  • [21:25:18] * RogerMonk (n=a0740758@nat/ti/x-76796c61f33bce81) has joined #beagle
  • [21:25:37] * GeneralAntilles (n=GeneralA@pdpc/supporter/active/generalantilles) Quit ()
  • [21:25:44] <Crofton> RogerMonk, ping
  • [21:25:45] <sakoman__> Seems that something is just not right with i2c
  • [21:25:55] <Crofton> sakoman, I have the same feeling
  • [21:26:08] <Crofton> not that I can base this on anything
  • [21:26:25] <sakoman__> I base it on the difference between evm and beagle
  • [21:26:47] <sakoman__> and the fact that I get a huge number of i2c related messages on beagle
  • [21:26:48] <RogerMonk> Crofton: pong
  • [21:27:15] <Crofton> there may be some dsp interfacing questions come up on this list
  • [21:27:24] * Crofton should have done this in #davinci
  • [21:27:29] <RogerMonk> ok - no worries
  • [21:27:58] <Crofton> http://listserv.vt.edu/archives/sffsdr.html
  • [21:28:44] <ds2> which I2C goes to the triton?
  • [21:28:58] <Crofton|work> I'm not sure if you are one of those compulsive list subscribers
  • [21:29:19] <RogerMonk> Crofton - u think I should join?
  • [21:29:28] <Crofton> up to you
  • [21:29:39] <Crofton> traffic is not too bad
  • [21:29:47] <RogerMonk> ok
  • [21:29:50] <ds2> Crofton: btw, what are you planning for a frontend to the beagle for SDR?
  • [21:30:01] <Crofton> I am hopefuly the usrp work
  • [21:30:16] <Crofton> also A guy I know may do one to interface via expansion connector
  • [21:30:34] <ds2> an ADC on the expansion connector McBSP?
  • [21:30:41] <Crofton> yeah
  • [21:30:53] <Crofton> with an fpga to do heavy lifting
  • [21:30:59] <ds2> ah like that
  • [21:31:29] <Crofton> RogerMonk, the sffsdr board was a joint project with TI, Xilinx, and Lyrtech, and likely some sw vendors
  • [21:31:39] <ds2> was thinking... if someone made a fast flash serial ADC, it could just go on the McBSP then add a preamp up front and that's it
  • [21:32:01] <Crofton> fpga can cut the data rate a lot :)
  • [21:32:12] <ds2> fpgas are power hungry :P
  • [21:32:13] <Crofton> leaves more cycles for application work in the beagle
  • [21:32:59] <Crofton> true
  • [21:33:10] <ds2> once the beagle gets to the final form, maybe someone could fab a board with a fpga tacked on it
  • [21:33:32] <ds2> hardest part might be finding an investor so you can get the OMAP3 at the volume pricing
  • [21:33:32] <Crofton> wideband tuning is hard in RF
  • [21:33:59] <Crofton> I suspect people are already looking at this :)
  • [21:34:01] <ds2> heh you don't tune it...sample everything from DC to 5-10GHz
  • [21:34:21] <ds2> and hope there is no overly strong signal or have a very good dynamic range
  • [21:36:07] <ds2> think the spec an folks are doing stuff like that
  • [21:43:06] * bazbell (n=a0192809@nat/ti/x-7991a5ec76aa92f8) has joined #beagle
  • [21:47:36] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) Quit ("Leaving.")
  • [21:56:58] <banderson> Does anyone know of documentation explaining how to create an "application" sdk for ppl that are just going to create apps under oe (angstrom/omap3)
  • [21:57:36] <banderson> Thought I read/watched that it was possible to do so using oe...
  • [22:04:54] * rsalveti (n=salveti@200.184.118.132) Quit (Read error: 113 (No route to host))
  • [22:12:26] * hagisbasheruk (n=hagisbas@cpc4-clyd1-0-0-cust357.renf.cable.ntl.com) Quit (Read error: 110 (Connection timed out))
  • [22:17:33] <Crofton> I think the meta-toolchain target does that
  • [22:18:09] <Crofton> I ahven't followed this closely, but it is a huge issue, how to use OE for dev, as opposed to distro/image buidling
  • [22:18:24] <Crofton> well, unless you use bitbake to do dev builds :)
  • [22:19:58] <Crofton> look at org.openembedded.dev/packages/meta/meta-toolchain.bb
  • [22:20:00] <Crofton> and friends
  • [22:20:05] <banderson> Thanks!
  • [22:20:43] * mru never got along with "sdk" packages
  • [22:20:43] <Crofton|work> getting this stuff in good shape would be really awesome
  • [22:23:04] <banderson> I liked the concept of it because there are going to be developers working on our product that don't have Linux experience and I would like to keep the complexities of uImage/cross-compile tools/rootfs away from them while still giving client the ability to build all from source.
  • [22:23:16] <Crofton|work> yeah
  • [22:23:26] <Crofton|work> openmoko really sees this issue
  • [22:23:45] <Crofton|work> people *want* sdk's
  • [22:24:15] <Crofton|work> I don't mind putting together a bb file, but I already have OE going and am comfortable with it
  • [22:24:29] <Crofton|work> but to pick up the causual dv, you need "sdk's"
  • [22:24:55] <banderson> should prob poke around openmoko site to for clues.
  • [22:25:14] <Crofton|work> yeah, I do not know what they ended up doing
  • [22:25:20] <Crofton|work> I know there was a lot of friction
  • [22:25:48] <sakoman__> koen, Crofton: I throttled back the i2c-1 data rate in my kernel from 2600 to 400
  • [22:26:07] <sakoman__> haven't gotten an i2c error since then
  • [22:26:07] <jkridner|work> I haven't read this whole conversation, but can't you put an installer around OE and make it the basis for an SDK?
  • [22:26:11] <Crofton|work> hmmm
  • [22:26:14] <sakoman__> but still in early testing
  • [22:26:20] <ds2> sakoman: is i2c-1 the one with the triton on it?
  • [22:26:24] <sakoman__> yes
  • [22:26:47] <ds2> odd that you would have problems on that
  • [22:27:14] <sakoman__> I don't think it is just me!
  • [22:27:31] <Crofton|work> does this help sound stability?
  • [22:27:34] <banderson> jkridner: that is an option I thought about. Another one was getting a debian vmware configure with oe and just give them that.
  • [22:28:34] <banderson> I have many i2c related "weirdness" on my evm...
  • [22:28:35] <jkridner|work> can you build that vmware file system with OE itself?
  • [22:29:04] <banderson> jkridner: There is a thought!!
  • [22:29:15] <ds2> there are so many things on the 4030 that the system would crumble if that fell apart
  • [22:29:20] <banderson> jkridner: would make upgrade easier
  • [22:29:39] <jkridner|work> I pretty much want to do that for my EC2 setup.
  • [22:29:47] <sakoman__> Crofton: still testing but I haven't had a failure yet
  • [22:29:57] <jkridner|work> It is always a big deal for me when a project reaches the point where it can built itself.
  • [22:30:37] <ds2> jkridner: fan of reprap? :)
  • [22:30:59] <jkridner|work> I'm going to want to build my Amazon EC2 machine images with OE to allow for upgrades of the machines I use for parallel builds.
  • [22:31:11] <sakoman__> ds2: when i2c-1 goes wonky the system does pretty much crumble
  • [22:31:27] <sakoman__> when you see that you know it is immediate reboot time
  • [22:31:29] <ds2> ah
  • [22:31:39] <jkridner|work> ds2: I've seen similar machines. And, yes.
  • [22:31:56] <ds2> IIRC, even the reset button fails to work if the twl4030 gets really upset
  • [22:32:03] <jkridner|work> to me, it is important to reach that level of self-sufficiency.
  • [22:33:06] <banderson> sakoman: I still havn't got to the bottem of why I see the i2c halt on some boots on evm. If you remember last thursday I found that it gets into inf loop waiting for a bit to flip.
  • [22:36:52] <jkridner|work> ds2: this reprap thing is intriguing.
  • [22:37:28] <ds2> intriguing enough to say, get the software running on a beagle? :)
  • [22:38:02] * rsalveti (n=salveti@189.70.140.74) has joined #beagle
  • [22:39:04] * mickeyl (i=mickey@openmoko/coreteam/mickey) has joined #beagle
  • [22:39:54] <jkridner|work> Intriguing enough to give a start in that direction at least. I need to figure out how to get one of these things so that I can make a few more.
  • [22:40:06] <sakoman__> banderson: might be worth trying to throttle back i2c data rate to see if it makes any difference
  • [22:41:58] * prpplague (n=dave@mail.americanmicrosystems.com) Quit ("Leaving")
  • [22:43:31] <Crofton|work> What sort of things do you need for the average customer to do dev for the beagle
  • [22:44:41] <ds2> make CC=arm_unknown_linux_gnu-gcc
  • [22:44:49] <ds2> none of that bb crap ;)
  • [22:45:08] <Crofton|work> heh
  • [22:45:30] <mickeyl> *cough*
  • [22:45:31] <Crofton|work> the problem is you need more than just a c compiler
  • [22:45:46] <Crofton|work> you need a coherent set of libraries to build against
  • [22:45:47] <ds2> Crofton: what more do you need?
  • [22:46:05] <ds2> use cross tools to build the C libs
  • [22:46:05] <Crofton|work> say you are creating an X app
  • [22:46:11] <Crofton|work> and X
  • [22:46:21] <Crofton|work> and various other libraries
  • [22:46:26] <ds2> packages that link in the kitchen sink are just poorly designed
  • [22:46:43] <Crofton|work> the end user needs to be provided with a sane build environment
  • [22:47:09] <Crofton|work> the target audience is people getting started in embedded dev, with TI products
  • [22:48:22] <ds2> if they need that much hand holding, they should just use an off the shelf commercial product
  • [22:48:22] <Crofton|work> I would guess jkridner wants people to create really cool stuff for the beagle
  • [22:49:13] <ds2> plenty of dev tools in that area; none of which I'd touch with a 40meter pole though
  • [22:49:30] <Crofton|work> If we want to promote the free software agenda, we need to make things easier for the casual devs
  • [22:49:39] <Crofton|work> in case they have a genius idea
  • [22:49:58] <ds2> how do you define a casual dev?
  • [22:50:12] <Crofton|work> make CC=arm_unknown_linux_gnu-gcc
  • [22:50:26] <Crofton|work> except they want access to libraries installed on the hw
  • [22:50:39] <ds2> problem with embedded is you donno what is installed unless you install it
  • [22:50:59] <ds2> so I much rather see they build the whole thing and refer to .a's instead of all the .so's
  • [22:51:13] <mru> allowing casual devs to write code only brings casualties
  • [22:51:14] <Crofton|work> but with the meta-toolchain target, we can create a toolchain that has access to the libraries in the imager
  • [22:52:05] <Crofton|work> mru, casual devs are customers :)
  • [22:53:07] <ds2> heh... customers? the one who bulk at the $100/singles price ?
  • [22:53:09] <jkridner|work> mickeyl: trying to get someone's attention?
  • [22:53:39] <ds2> look at this abomination of "configure" and libtool
  • [22:53:47] <ds2> complete utter hinderance at proper development
  • [22:53:57] <mru> indeed
  • [22:53:58] <mickeyl> jkridner|work: no, thanks. it was just a spontaneous reaction to ds2's sentence :)
  • [22:54:01] * GeneralAntilles (n=GeneralA@c-69-244-211-19.hsd1.fl.comcast.net) has joined #beagle
  • [22:55:10] <ds2> mickeyl: which one? bb or ?
  • [22:55:21] <mickeyl> *nod*
  • [22:55:32] <jkridner|work> ah
  • [22:55:54] <ds2> mickeyl: sorry, but I am not convinced such a tight package is a good thing.
  • [22:56:30] <mickeyl> no problem. we all have different approaches
  • [22:56:38] <ds2> *nod*
  • [22:57:18] <Crofton|work> you need to work out the audience
  • [22:57:34] <Crofton|work> I suspect the TI guys have really good data on their audience
  • [22:57:38] * cwz (n=chris@mekaneck.topdogpc.com) Quit (Read error: 113 (No route to host))
  • [22:58:58] <sakoman__> heh, bush is coming to visit this week
  • [22:59:08] <sakoman__> wants to see the fires I guess
  • [22:59:12] <calculus> how has the maemo folks done their development tools for the casual dev?
  • [22:59:19] <Crofton|work> hmmm, not enough in DC?
  • [22:59:44] <mru> maemo is no fun at all
  • [22:59:50] <sakoman__> probably felt upstaged by the governator
  • [22:59:53] <jkridner|work> calculus: I've used the VMware image for casual dev on Maemo.
  • [23:00:19] * bazbell (n=a0192809@nat/ti/x-7991a5ec76aa92f8) Quit (Remote closed the connection)
  • [23:00:20] <jkridner|work> I wouldn't say it was no fun at all, but it wasn't as easy entry as I'd like.
  • [23:00:33] <mru> I guess I never tried hard enough
  • [23:00:51] <mru> I just want to run my cross-compiler
  • [23:00:52] <jkridner|work> and, I didn't get very far. Lots of click-ware stuff to install, even after the getting the VMware image, and lots of things left to configure still.
  • [23:01:05] <mru> not spend hours and gigabytes setting up "environments"
  • [23:01:41] <mru> and all the fun stuff hiding behind proprietary libs anyway
  • [23:01:56] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [23:01:59] * bazbell (n=a0192809@nat/ti/x-c0da236d7ba58428) has joined #beagle
  • [23:03:18] <jkridner|work> I'd be really interested in hosting and environment for Beagle devs on EC2 for "trials", perhaps even accepting job submissions of some kind (perhaps OE git trees and target packages?), but it can't be something that is for more than playing around.
  • [23:03:20] <calculus> I can see tools like this being helpful to the omap community... e.g. some set of tools and the casual dev can build for pandora, beagleboard, ...
  • [23:03:46] <calculus> maybe a cross-product/team effort
  • [23:04:15] <ds2> jkridner: something like a tinderbox thing?
  • [23:04:49] <mru> well, personally I have no interest whatsoever in the kind of stuff your average "casual dev" comes up with
  • [23:04:50] <Crofton|work> basically, I see OE creating the base sw delivered with the beagleboard, and provide a sdk for people to use
  • [23:05:14] <jkridner|work> I think tinderbox is just a data collector...
  • [23:05:17] <Crofton|work> people interested creating customs images would pick up OE and create new images
  • [23:05:23] <jkridner|work> I believe Angstrom also has an autobuilder.
  • [23:05:39] * mickeyl is now known as mickey|zzZZzz
  • [23:06:40] <Crofton|work> autobuilders are good for catching bad commits to OE
  • [23:06:52] <Crofton|work> and creating loads of images
  • [23:06:53] <jkridner|work> for (very casual) app dev, I'd think that could be done (for Beagle) on the Beagle itself.
  • [23:07:13] <jkridner|work> (I'd want to spawn to a bigger machine for larger build jobs)
  • [23:08:08] <jkridner|work> Crofton|work: I'd think that autobuilders could also be used for casual devs just looking, without wanting to install even Linux, let alone OE.
  • [23:08:19] <Crofton|work> rumor has it ipkg install gcc might work :)
  • [23:08:31] <jkridner|work> It isn't that installing OE is all that painful, but it is very distro dependent and you can get stuck at many points.
  • [23:09:21] <Crofton|work> it is easy after you have done it a dozen times :)
  • [23:09:41] <sakoman__> FWIW, still no i2c-1 errors
  • [23:09:55] <Crofton> hmmm, I need to try this
  • [23:10:05] <Crofton> maybe it will help my sound problem
  • [23:10:13] <jkridner|work> For the trainings I've (not) been working on, they are based on running gcc, perl, and python on Beagle directly. All of those languages are running reasonably well.
  • [23:10:30] <Crofton|work> cool
  • [23:10:54] <sakoman__> not sure it needs to go all the way down to 400 from 2600, but I wanted to try something really conservative
  • [23:11:06] <Crofton|work> it is only recently that self hosting was possible for embedded systems
  • [23:11:09] * jkridner|work pounds his head a couple more times trying to figure out who needs to get involved to make these I2C issues go away once and for all.
  • [23:11:35] <sakoman__> I suspect maybe pull ups are too weak for 2600??
  • [23:12:00] <mru> I was just thinking that running compilers on the beagle sounded painful, then realised it wasn't that long ago workstations had similar specs
  • [23:12:10] <Crofton|work> right
  • [23:12:19] <Crofton|work> 486 25 Mhz
  • [23:12:22] <Crofton|work> hot shit
  • [23:12:35] * mru looks at the 500MHz Alpha sitting in the corner
  • [23:13:08] <mru> that machine doesn't see much use these days
  • [23:13:18] <mru> did serve me well, though
  • [23:15:28] <bjdooks> sakoman__: what values are the pull ups?
  • [23:15:44] <Crofton|work> the beagle does have a kb, mouse and screen though
  • [23:15:56] <Crofton|work> not an option on many of the OE targets :)
  • [23:16:06] <sakoman__> bjdooks: don't know -- was just looking for the schematics
  • [23:16:21] <bjdooks> sakoman__: is 2600 = 2.6MHz, or some other unit of measuring speed?
  • [23:16:53] <sakoman__> I assume 2.6Mhz
  • [23:17:11] <ds2> tinder box is nice in that it also generates status web pages
  • [23:17:25] <bjdooks> sakoman__: i2c isn't really meant to operate over 400KHz
  • [23:17:40] <ds2> but whatever is easiest is nice; it'll be good to have sample binary images for sanity checking after a board is shipped
  • [23:17:46] <bjdooks> unless all of the client chips can run fast
  • [23:17:48] <Crofton|work> ok, I need to attend to real life
  • [23:18:05] <bjdooks> and then at those speeds you probably want current-sources as bus termination instead of resistors
  • [23:18:33] <banderson> sakoman: where are you changing data rate i2c-omap.c?
  • [23:18:51] <sakoman__> banderson: it is in the board file
  • [23:19:11] <sakoman__> - omap_register_i2c_bus(1, 2600, NULL, 0);
  • [23:19:11] <sakoman__> + omap_register_i2c_bus(1, 400, NULL, 0);
  • [23:21:05] <sakoman__> looks like the pull-ups are 4.7K to 1.8V
  • [23:23:34] <banderson> sakoman: How come only first bus was set to 2600?
  • [23:24:55] <banderson> sakoman: I guess the real question is whether the other to i2c busses are different.
  • [23:25:03] <banderson> s/to/two
  • [23:25:27] <sakoman__> That's the way TI set it up in the original board file -- I assume i2c-1 channel is the only high speed one
  • [23:25:38] <banderson> I see
  • [23:25:51] <sakoman__> But I haven't read that section of the docs -- that is just an assumption
  • [23:26:10] <sakoman__> I hadn't really looked at this stuff too closely till today
  • [23:26:46] <sakoman__> Other than adding the missing pullups to i2c-2 on my board to eliminate the timeout errors
  • [23:28:03] <bjdooks> sakoman__: 4.7K usually means about 100-400KHz range
  • [23:28:33] <sakoman__> bjdooks: that's what I remember from my previous life as an EE
  • [23:28:44] <sakoman__> and that's the value I used on i2c-2
  • [23:30:29] <sakoman__> Crofton, koen: I've been using my own evm demo image for beagle testing up to now. I wanted to try beagle-demo-image, but the build fails on gst-ffmpeg
  • [23:30:41] <ds2> sakoman__: what does the EVM use as far as the TWL4030 connected I2C bus speed?
  • [23:31:07] <sakoman__> Crofton, koen: http://www.sakoman.net:8000/public/logs/135908.txt
  • [23:31:15] <sakoman__> any suggestions?
  • [23:31:39] <sakoman__> ds2: I believe it is 2600 also
  • [23:32:29] <sakoman__> I have gotten i2c-1 errors two or three times with the evm, but much, much less frequently than on beagle
  • [23:33:11] <ds2> sakoman__: Hmm
  • [23:33:23] <banderson> on evm i2c-1 is set to 2600. I am testing it to see if my errors that I see on evm go away.
  • [23:33:43] <sakoman__> ds2: just checked schematic, evm also uses 4.7K pullups
  • [23:33:45] <bjdooks> grr, 70eu down the drain due to the difference between measuring from pcb edge to connector instead of connector to connector
  • [23:33:46] <ds2> the SDP has it at 2600 also and that works fine
  • [23:34:56] <sakoman__> ds2: still a theory. let's see if others can eliminate the i2c-1 wonkiness by slowing things down
  • [23:35:15] <ds2> how many versions of the EVM are there?
  • [23:35:35] <bjdooks> ds2: it could also depend on how long the bus is (affects capacitance), i'd not run anything with 4.7K pullups over 400KHz
  • [23:36:08] <ds2> I'd think of all the boards, the SDP should have the longest physical bus
  • [23:37:03] <ds2> sakoman__: I have a different theory that points elsewhere; just donno if I can discuss it
  • [23:38:14] <banderson> Was it aliens?
  • [23:38:25] <sakoman__> ds2: any workarounds we can try to test your theory without discussing it?
  • [23:38:50] <ds2> sakoman__: no, my observations point to something not in the kernel
  • [23:39:27] <sakoman__> ds2: any u-boot workarounds we can try/ ;-)
  • [23:39:51] <ds2> =) without explaining why; no.
  • [23:43:38] * RogerMonk (n=a0740758@nat/ti/x-76796c61f33bce81) Quit (Remote closed the connection)
  • [23:57:25] * jkridner|work (n=a0321898@nat/ti/x-6984fb637d169014) Quit ("Leaving.")