• [00:02:18] * Olipro_ (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [00:09:12] * Olipro__ (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [00:20:58] * Olipro_ (i=Olipro@unaffiliated/olipro) Quit (Connection timed out)
  • [00:22:02] * Olipro (i=Olipro@unaffiliated/olipro) Quit (Read error: 110 (Connection timed out))
  • [00:26:05] * Olipro (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [00:44:00] * Olipro__ (i=Olipro@unaffiliated/olipro) Quit (Connection timed out)
  • [01:17:20] * RogerMonk (n=a0740758@nat/ti/x-40e9fbedd82cf4a1) Quit (Remote closed the connection)
  • [01:31:56] * bazbell (n=a0192809@nat/ti/x-d05dff02639cd300) has joined #beagle
  • [03:22:52] * sakoman__ (n=sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) Quit ("Ex-Chat")
  • [03:23:09] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [03:38:35] * Beagle6 (n=Beagle6@5ad8b120.bb.sky.com) has joined #beagle
  • [03:39:16] * Beagle6 (n=Beagle6@5ad8b120.bb.sky.com) Quit (Client Quit)
  • [03:53:49] <jkridner> sakoman, sakoman__: I sent you links to files that should help you find components easier.
  • [03:58:00] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [04:01:36] * bazbell (n=a0192809@nat/ti/x-d05dff02639cd300) Quit ("Leaving.")
  • [04:13:47] <jkridner> good morning khasim
  • [04:14:03] * sakoman_ (n=sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) has joined #beagle
  • [04:14:46] <jkridner> koen was asking about demo kernels and wanting to try out the 3D demos.
  • [06:37:33] * mickey|zzZZzz is now known as mickeyl
  • [06:51:11] * trickie|away is now known as trickie
  • [06:58:17] * gadiyar (n=a0393673@192.163.20.231) has joined #beagle
  • [06:58:53] <gadiyar> koen: ping
  • [07:04:22] * ali_as (n=ali_as@ambix.plus.com) has joined #beagle
  • [07:16:59] * ali_as_ (n=ali_as@ambix.plus.com) Quit (Read error: 110 (Connection timed out))
  • [07:20:05] * esden`aw` is now known as esden
  • [07:27:21] * gadiyar (n=a0393673@192.163.20.231) has left #beagle
  • [07:56:29] * Blackhold (n=Blackhol@203.Red-80-34-166.staticIP.rima-tde.net) has joined #beagle
  • [07:56:39] * Blackhold (n=Blackhol@203.Red-80-34-166.staticIP.rima-tde.net) Quit (Client Quit)
  • [08:01:55] * esden is now known as esden`away
  • [08:03:58] <khasim> Koen: ping
  • [08:07:35] <koen> pong
  • [08:10:02] * intu (n=intu@ubr1-201-91.ubr.tartu.stv.ee) Quit ("Leaving.")
  • [08:30:27] * esden`away is now known as esden
  • [08:56:02] <koen> aha!
  • [08:56:03] <koen> 23:05 * Crofton curses trailing spaces
  • [08:56:17] <koen> I now know what he meant :)
  • [08:56:23] * koen curses trailing spaces as well
  • [09:40:13] * mickeyl is now known as mickey|lunch
  • [09:43:50] <khasim> koen: sorry, I was away from my desk for a while,
  • [09:44:41] <khasim> koen: I saw jkridner reporting some requirements for LUR, are you in need of any thing?
  • [09:45:24] <khasim> How do I get a notification when my name is mentioned on the list using Pidgin?
  • [09:45:50] <khasim> I will have my pidgin screen minimized, and loose all important discussions
  • [09:46:11] * lardman|gone is now known as lardman
  • [09:47:24] <koen> khasim: iirc there's a plugin you can activate for that
  • [09:48:17] <koen> khasim: having access to the 3d demos before LRL would be nice, but I'll have no time for that today, so I'll look at it when I'm at TI northampton
  • [09:50:26] <khasim> koen: will you be meeting Roger Monk their?
  • [09:50:43] <khasim> koen: he has access to 3D demos and corresponding Images as well
  • [09:52:50] <koen> yes
  • [09:56:17] * koen_ (n=koen@s55917625.adsl.wanadoo.nl) has joined #beagle
  • [10:03:03] <ldesnogu> I guess the 3d demos can't be freely distributed yet, right? Also it seems they are running using the framebuffer directly?
  • [10:13:26] * koen (n=koen@s55917625.adsl.wanadoo.nl) Quit (Nick collision from services.)
  • [10:13:39] * koen_ is now known as koen
  • [10:40:33] * RogerMonk (n=a0740758@nat/ti/x-b9b340259da44b6f) has joined #beagle
  • [11:17:51] <Crofton> koen, the patch probably did not make it clear that I had to drop a trialing space in one line :)
  • [11:18:57] <koen> Crofton: http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=commitdiff;h=a0fcae23770a22d2242c4ee386db8a97ff3592d7
  • [11:23:15] <koen> js: "/OE/angstrom-tmp/work/neuros-osd2-angstrom-linux-gnueabi/codec-engine-2.10-r4/codec_engine_2_10_01/packages/config.bld", line 132: exception from uncaught JavaScript throw: Error:
  • [11:23:21] <koen> Javascript?!?!?!?
  • [11:25:00] <Crofton> eventually, we need to figure out how to "stage" dsp libraries so you can build user supplied code
  • [11:33:06] <jkridner> good morning.
  • [11:34:00] <koen> hey jkridner
  • [11:36:12] <koen> someone at TI will get a nervous breakdown when MV changes their toolchain prefix
  • [11:36:36] <RogerMonk> Koen - you worry too much :)
  • [11:36:57] <RogerMonk> We can't make this stuff too easy :)
  • [11:38:55] <koen> seriously, javascript in your builsystem?
  • [11:39:10] <RogerMonk> yep
  • [11:39:17] <RogerMonk> that's how the config stuff works
  • [11:39:40] * Olipro_ (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [11:39:53] * Olipro (i=Olipro@unaffiliated/olipro) Quit (Nick collision from services.)
  • [11:39:54] * Olipro_ is now known as Olipro
  • [11:40:29] <koen> anyway....
  • [11:40:45] <koen> the DSP side build seems to be working for link and CE now
  • [11:40:50] <koen> (for davinci)
  • [11:41:01] <RogerMonk> great
  • [11:41:17] <RogerMonk> does it work?
  • [11:43:17] <koen> dunno
  • [11:43:35] <koen> note that I didn't say that the ARM side build works ;)
  • [11:43:57] <RogerMonk> ah-ha!
  • [11:47:12] <koen> make[1]: Entering directory `/OE/angstrom-tmp/work/neuros-osd2-angstrom-linux-gnueabi/codec-engine-2.10-r4/codec_engine_2_10_01/examples/ti/sdo/ce/examples/apps/speech/linuxonly'
  • [11:47:16] <koen> /OE/angstrom-tmp/cross/bin/arm-angstrom-linux-gnueabi-gcc -c -g -Wall -Os -o app.o app.c
  • [11:47:19] <koen> app.c:14:21: error: xdc/std.h: No such file or directory
  • [11:59:06] <Crofton|work> RogerMonk, any hints on building dsplink for a machine with 128M of RAM?
  • [12:00:45] <RogerMonk> yep - I'll help u with that
  • [12:01:03] <Crofton|work> is it in the docs?
  • [12:01:04] <RogerMonk> lets make sure it works with 256 though first
  • [12:01:18] <RogerMonk> probably.... but it's easier to tell u
  • [12:01:26] <Crofton|work> heh
  • [12:01:29] <Crofton|work> ok
  • [12:01:51] * RogerMonk heads for some lunch - back later to make dsplink work...
  • [12:01:56] <koen> the swfdec author will be at LRL
  • [12:07:45] * bazbell (n=a0192809@nat/ti/x-2c61d30a337b9340) has joined #beagle
  • [12:15:03] * BThompson (n=BThompso@nat/ti/x-57502b259608246d) has joined #beagle
  • [12:27:16] * lardman is now known as lardman|lunch
  • [12:35:30] * lardman|lunch is now known as lardman
  • [12:36:01] <jkridner> I like JavaScript, if you leave out the DOM. The DOM is what most people experience with JavaScript and hate.
  • [12:36:17] <jkridner> BeagleBoard.org server is even written in JavaScript.
  • [12:36:55] <Crofton> jkridner, the world needs fewer buildsystems :)
  • [12:37:15] <jkridner> very true. I won't argue against that.
  • [12:37:22] <jkridner> fewer build systems and packaging systems.
  • [12:38:05] <Crofton> yep
  • [12:38:23] <jkridner> and fewer programming languages. :)
  • [12:38:30] <jkridner> only the ones I like. ;)
  • [12:38:40] <Crofton> right, only c++
  • [12:38:52] <jkridner> eww. ;)
  • [12:40:45] <jkridner> must include 'eval' so that your ugly hack of self-modifying code can be semi-readable and justified, despite being a really bad idea.
  • [12:42:03] * jkridner prefers C to C++, still, and is headed out to the office.
  • [12:45:39] <Crofton|work> tony is reading email again ...
  • [12:46:35] <koen> Crofton|work: I update the kernel to 2.6.26, tony updated it today
  • [12:46:58] <Crofton|work> hopefully he gets patches integrated also
  • [12:48:05] <koen> Crofton|work: notice how nice PV looks :)
  • [12:50:35] <Crofton|work> Can I do PV_machine ="N" ?
  • [12:50:54] <Crofton|work> er PR I mean :)
  • [12:51:00] <koen> yes, but that won't work as expected
  • [12:51:06] <Crofton|work> heh
  • [12:51:07] <Crofton|work> ok
  • [12:51:28] <Crofton|work> I need to build some test version of u-boot for the sffsdr baord, and want to bump PR
  • [12:51:42] <koen> PRs are cheap
  • [12:51:53] <koen> it's not like building uboot takes eons :)
  • [12:52:06] <Crofton|work> yeah
  • [12:55:05] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has joined #beagle
  • [13:15:39] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has left #beagle
  • [13:18:33] <koen> aaargh
  • [13:18:42] <koen> CE uses CPPFLAGS for .c files....
  • [13:20:16] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has joined #beagle
  • [13:29:00] <ldesnogu> CPPFLAGS is for preprocessor, CXXFLAGS for C++
  • [13:31:06] <ldesnogu> gmake default rule for .c compilation is $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
  • [13:31:19] <ldesnogu> anyway that probably won't ease your pain :)
  • [13:31:36] * jkridner|work (n=a0321898@nat/ti/x-3ba56964960859ec) has joined #beagle
  • [13:33:08] <koen> ah
  • [13:33:22] <koen> I always get confused between CPPFLAGS and CXXFLAGS
  • [13:36:16] <koen> well, the builds gets further now
  • [13:36:52] <koen> most likely wrong includes paths
  • [13:37:24] <bjdooks> CPPFLAGS is for the pre-processor, CXX is for dirty code
  • [13:37:39] <RogerMonk> koen - send logs
  • [13:37:42] <RogerMonk> pls
  • [13:39:56] <koen> RogerMonk: http://amethyst.openembedded.net/~koen/dsplink/codec-engine-2.10.log.txt
  • [13:50:48] <jkridner|work> sakoman: Gerald has called a production stop until we resolve your I2C issue. You have my (almost) full attention now.
  • [13:51:05] <jkridner|work> I'm going to go run down the location of R11 and R12 now.
  • [13:58:16] <jkridner|work> sakoman, sakoman_: k, scott helped me find the resistors.
  • [13:58:28] <jkridner|work> both are on the bottom.
  • [13:58:48] * prpplague (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [13:59:09] <jkridner|work> You should know well where D3 is. R11 is immediately to the right of D3, if you have the board oriented to read "beagleboard.org" on the bottom.
  • [14:00:49] <jkridner|work> it is about 6mm or so away from D3.
  • [14:01:11] <jkridner|work> R12 is right between C18 and C13.
  • [14:16:25] <sakoman> jkridner: thanks! I'll probe and look at the signals
  • [14:19:24] * lardman is now known as lardman|gone
  • [14:20:35] <jkridner|work> RogerMonk seems to have seen a board with an I2C issue when talking to the MMC/SD that escaped test coverage. My guess is that it is a software config issue, but this needs to be confirmed quickly or Gerald won't finish making the boards.
  • [14:21:25] <jkridner|work> I'm going to hook my scope up which has been just sitting around for a couple of months.
  • [14:21:57] <koen> jkridner|work: also try sakoman's uboot, he fixed some compiler related i2c bugs
  • [14:22:53] <suihkulokki> great, the dspbridge people went ahead and renamed HAL to HW and OSAL to SERVICES
  • [14:24:09] <koen> gotta love sed :)
  • [14:35:30] * vsriram (i=7aa60de8@gateway/web/ajax/mibbit.com/x-b1e6fdba372464b3) has joined #beagle
  • [14:38:46] <sakoman_> jkridner: Probed the i2c-1 clock line
  • [14:39:06] <sakoman_> with my kernel mod, clock is 400Khz as expected
  • [14:40:00] * paul_pwsan (n=paul@utopia.booyaka.com) has joined #beagle
  • [14:40:04] <sakoman_> rise time looks to be 80-100ns
  • [14:40:14] <paul_pwsan> hello everyone
  • [14:40:24] <koen> hey paul_pwsan
  • [14:40:24] <paul_pwsan> spent a fair chunk of yesterday looking at some of the i2c issues
  • [14:40:28] <Crofton> gm
  • [14:40:32] <paul_pwsan> from the software side
  • [14:40:33] <sakoman_> fall time is > 200ns!
  • [14:40:45] <paul_pwsan> tried sakoman's suggestion to turn i2c clock down to 400KHz
  • [14:40:49] <koen> paul_pwsan: sakoman has been looking at the hw side :)
  • [14:40:49] <paul_pwsan> did not seem to help
  • [14:40:58] <paul_pwsan> heh
  • [14:41:09] <paul_pwsan> yeah it is quite a baffling problemset
  • [14:41:52] <paul_pwsan> made even more complicated since very few ppl have the twl4030 trm
  • [14:42:20] <koen> sakoman should have a copy
  • [14:43:03] <paul_pwsan> yeah, have one here too
  • [14:43:19] <paul_pwsan> so TWL4030 has this two-level interrupt architecture...
  • [14:43:39] <sakoman_> jkridner: I find it somewhat strange that the clock fall time is so long. I would expect that to be the faster edge.
  • [14:43:41] <paul_pwsan> PIH registers combine the interrupts from various TWL4030 subcomponents, "SIH"
  • [14:44:02] <paul_pwsan> secondary interrupt handlers, or something, i suppose
  • [14:44:32] <sakoman_> jkridner: I will look now with the HS mode enabled at 2600
  • [14:45:03] <paul_pwsan> so, started focusing on the "irq 368" issue
  • [14:46:01] <paul_pwsan> in drivers/i2c/chips/twl4030-core.c, line 490 or so,
  • [14:46:40] <sakoman_> paul_pwsan: sounds good. I believe that there are likely several i2c issues
  • [14:46:46] <paul_pwsan> added some printk to print the contents of the pih_isr registers, since that is how interrupts show up
  • [14:47:35] <paul_pwsan> and discovered at first that the twl4030 was getting a bunch of gpio0 interrupts - which according to the bboard ref man is the MMC card detect interrupt
  • [14:47:49] <paul_pwsan> (this is when beagle is booting from MMC)
  • [14:48:09] <paul_pwsan> baffling since gpio0 interrupts should be masked at that point
  • [14:48:34] <paul_pwsan> by twl_init_irq() in the same fine, line 837
  • [14:48:41] <paul_pwsan> er "file"
  • [14:49:08] <paul_pwsan> so tried adding a wmb() after the last interrupt mask write in twl_init_irq(),
  • [14:49:34] <paul_pwsan> and then the pih_irq value changed from 0x1 to 0x2! (for keypad interrupts)
  • [14:49:41] <paul_pwsan> kind of nonsensical
  • [14:50:42] <sakoman_> paul_pwsan: if i2c transactions are flake one might see all sorts of nonsensical stuff
  • [14:50:45] <paul_pwsan> yeah
  • [14:50:47] <paul_pwsan> anyway
  • [14:51:06] <paul_pwsan> i think it might be hardware too :-)
  • [14:51:29] <sakoman_> that slow fall time disturbs me
  • [14:52:10] <sakoman_> most open drain signals have slow rise and fast fall. this is the reverse
  • [14:52:33] <sakoman_> almost looks like a series resistor
  • [14:53:07] <Crofton> open source outputs?
  • [14:53:17] * Crofton realizes this is not sane ...
  • [14:53:26] <paul_pwsan> the one thing that i can't quite figure out about the hardware hypothesis,
  • [14:54:01] <sakoman_> Crofton: my open source outputs have been sub-par lately ;-)
  • [14:54:26] <paul_pwsan> is why the OMAP is getting interrupts. i haven't checked closely, but those come in on a dedicated line, right? not i2c
  • [14:54:30] <Crofton> heh
  • [14:54:49] <paul_pwsan> (although i suppose if the i2c writes to mask the interrupts are failing, then that might be it...)
  • [14:55:21] <paul_pwsan> (spurious interrupts from the TWL that is)
  • [14:55:38] <sakoman_> paul_pwsan: there is no separate int line for i2c. the interrupt is generated when an i2c transaction completes
  • [14:56:04] <paul_pwsan> both the I2C interrupt and the SYS_NIRQ interrupt?
  • [14:56:08] <sakoman_> if you are talking about i2c transaction ints
  • [14:56:36] <paul_pwsan> mostly SYS_NIRQ at this point
  • [14:56:40] <sakoman_> don't know about int lines from the twl4030. there may very well be one (or more)
  • [14:58:01] <paul_pwsan> (looking at beagle ref manual table 6)
  • [15:01:04] <sakoman_> paul_pwsan: yeah looks like a single int line from the 4030
  • [15:07:24] <sakoman_> jkridner: hmm . . . interesting
  • [15:07:47] <paul_pwsan> incidentally, does anyone else see occasional ECC boot failures from X-Loader?
  • [15:08:11] <sakoman_> the boot message says: i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
  • [15:08:13] <paul_pwsan> maybe 1 out of every 8 to 10 boots or so
  • [15:08:25] <sakoman_> but I still see a 400Khz signal
  • [15:08:35] <sakoman_> same lousy fall time
  • [15:08:38] <koen> paul_pwsan: I see those ecc errors sometimes
  • [15:09:09] <vsriram> could be a power issue
  • [15:09:19] <paul_pwsan> ok, just wondering if i had an unusually flaky board or something...
  • [15:09:30] <koen> sakoman: there was a mail about the sdp needing a specific i2c init sequence
  • [15:09:36] <sakoman_> paul_pwsan: yes I see those too
  • [15:09:44] <paul_pwsan> k thx
  • [15:10:02] <sakoman_> there was one day where it stuck in that ecc mode and would not boot at all
  • [15:10:21] <sakoman_> then it mysteriously healed itself and now just does it ocassionaly
  • [15:10:23] <koen> sakoman: http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=a5191ae92631eeb8fa66eaa3348c4031ac1ccab6
  • [15:10:32] <paul_pwsan> ouch. usually seems to go away after a couple of reset button pushes here
  • [15:10:41] <paul_pwsan> wonder if this is all some type of grounding issue?
  • [15:10:41] <koen> (beagle already inits i2c2 first)
  • [15:11:04] <sakoman_> thats the usual behaviour here too -- except for that one day
  • [15:14:10] <sakoman_> koen: no, beagle does 1,2,3 : http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/board-omap3beagle.c;h=fdce787e8ae5040f096dde591c02eaa87bfc75ea;hb=d3b3ae0fe6c71641da19c8de466ec366d39847e3
  • [15:14:22] <paul_pwsan> here's a little more grist for the mill, from the software side
  • [15:14:25] <paul_pwsan> good boot: http://pastebin.com/m6dd55989
  • [15:14:32] <paul_pwsan> bad boot: http://pastebin.com/m6b76d2be
  • [15:14:50] <paul_pwsan> this is with clock fw debugging enabled and those pih_isr printks() added
  • [15:15:26] <paul_pwsan> something is causing all of the PIH interrupts to be asserted in sequence
  • [15:15:58] <paul_pwsan> (each of those "clock stable" messages indicates one i2c xfer, btw)
  • [15:16:37] <paul_pwsan> current i2c-omap code enables and disables clocks to I2C controllers before and after every transfer
  • [15:27:43] <jkridner|work> sakoman: I missed the pings, since I'm on jkridner|work.
  • [15:28:07] <jkridner|work> I'll check if the resistor is too small, resulting in a long fall time.
  • [15:28:36] <jkridner|work> I could imagine that both internal pull-ups and external pull-ups could be in parallel, making the resistance fairly low.
  • [15:29:55] * docelic (n=docelic@78.134.201.183) has joined #beagle
  • [15:30:18] * dirk2 (n=dirk@F3258.f.strato-dslnet.de) has joined #beagle
  • [15:45:26] <sakoman_> jkridner|work: we also need to figure out why the clock rate is 400 when sw thinks it is 2600
  • [15:46:48] <sakoman_> I can't spend a huge amount of time on this today -- I have some deliverables for a client that i need to complete
  • [15:48:10] <dirk2> Looking at beagle HW manual rev B4 (page 117) I2C1 pull ups are 4,7k (or 47k? picture is too bad)
  • [15:50:30] <koen> ah, they put in jpegs of the schematics
  • [16:01:56] * mickey|lunch is now known as mickeyl
  • [16:05:25] <sakoman_> dirk2: they are 4.7K, which is fairly typical value for 400Khz i2c
  • [16:08:39] <dirk2> okay, and internal pull ups are on, too: line 635 http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=blob;f=include/asm-arm/arch-omap3/mux.h;h=ec4aeb0ddbac50cc01f486b055c6970ed87d03e6;hb=refs/heads/test
  • [16:11:56] <sakoman_> dirk2: yes my next step was to disable the internal pu to see what that does to the signal
  • [16:12:25] * jkridner|work (n=a0321898@nat/ti/x-3ba56964960859ec) Quit (Remote closed the connection)
  • [16:12:28] <sakoman_> have to do some paying work first though ;-)
  • [16:12:47] * jkridner|work (n=a0321898@nat/ti/x-7bbbfc52ad351d88) has joined #beagle
  • [16:16:37] <dirk2> We should try http://marc.info/?l=linux-omap&m=121614853008185&w=2 , too
  • [16:17:04] <sakoman_> for the record, 200ns fall time is within spec (300ns) for 400Khz mode
  • [16:17:06] <paul_pwsan> hi dirk2
  • [16:17:08] <ds2> 2 bits of info to consider if not already - there was a report that initing the I2C buses in a different order result in a hang (long time ago) and there was a inuse flag ordering patch yesterdya on the linux-omap list
  • [16:17:36] <ds2> dirk2: yeah, that one
  • [16:17:48] <paul_pwsan> at least in terms of the transmit overflow warnings and irq 368 messages, that patch doesn't seem to change anything
  • [16:17:54] <ds2> sakoman_: Have you tried recording the I2C bus and see what happens on the line when it fails?
  • [16:18:07] <sakoman_> ds2: no
  • [16:18:17] <ds2> sakoman_: do you have facilities to do that?
  • [16:18:27] <sakoman_> dirk2: I am already using that patch
  • [16:18:49] <sakoman_> ds2: I have the equipment, just not the time till later today
  • [16:18:54] <paul_pwsan> sakoman_: good to know re: fall time
  • [16:19:27] <ds2> hmm for a slow fall time, could there be too much capacitance?
  • [16:19:34] <sakoman_> the main mystery to me now is why the sw believes the data rate is 2600 but the hw is delivering 400
  • [16:20:33] <sakoman_> ds2: it is within spec
  • [16:20:33] <paul_pwsan> drivers/i2c/busses/i2c-omap.c:omap_i2c_init() lines 284 et seq
  • [16:20:54] <paul_pwsan> not sure exactly what it is doing.
  • [16:21:29] * vsriram (i=7aa60de8@gateway/web/ajax/mibbit.com/x-b1e6fdba372464b3) has left #beagle
  • [16:21:57] <sakoman_> will be back later
  • [16:22:06] <ds2> sakoman_: in spec, but is the cap excessive for the board
  • [16:22:22] <dirk2> mru: just read the logs from yesterday: thanks for the link to 600MHz uboot config
  • [16:22:26] <sakoman_> ds2: don't know
  • [16:25:25] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [16:25:33] <paul_pwsan> sakoman_, looks like the i2c-omap code never configures the controller for high-speed operation
  • [16:26:51] <paul_pwsan> sakoman_: never mind, it does it later at line 423
  • [16:31:27] <dirk2> Not sure if it might help, but Nishant did some (uboot) I2C driver cleanup for his UBoot v2: http://rafb.net/p/wzQZTP42.html Just fyi ;)
  • [16:36:40] <paul_pwsan> btw sakoman_, when you get back, would like to know what beagle pin you are using to monitor i2c1
  • [16:47:06] <paul_pwsan> so apparently in i2c high-speed mode, the bus transaction starts at 400KHz, then in the "second phase," goes up to high-speed
  • [16:47:25] <paul_pwsan> sakoman_, could be that your scope trigger is too early
  • [16:48:31] <dirk2> paul_pwsan: I2C1 pins: Can the log http://www.beagleboard.org/irclogs/index.php?date=2008-07-16#T13:50:48 help you until sakoman is back?
  • [16:49:36] <paul_pwsan> dirk2: thanks, will take a look
  • [16:50:30] <dirk2> paul_pwsan: D3 the log talks about is http://www.sakoman.net/omap3/beagle/vbus-mod-d3.jpg
  • [16:56:14] <sakoman_> paul_pwsan: back now
  • [16:56:24] <sakoman_> I am probing on r11 and r12
  • [16:56:42] * intu (n=intu@ubr1-201-91.ubr.tartu.stv.ee) has joined #beagle
  • [16:56:55] <sakoman_> I will look at later transactions to see if the speed bumps
  • [17:00:04] <paul_pwsan> sakoman_: thx, will try to put a scope on the board on my end later today
  • [17:05:20] <sakoman_> paul_pwsan: you are correct. the transaction does start at 400Khz and then switches to high speed
  • [17:05:50] <sakoman_> I need to fuss with my scope delay to try to catch the high speed section so I can look at the waveforms
  • [17:07:40] <paul_pwsan> sakoman_: good to hear, you just saved me a bunch of time today :-)
  • [17:12:38] <sakoman_> paul_pwsan: On my 100Mhz scope the clock looks more like a sine wave than a square wave
  • [17:13:24] <sakoman_> It does appear to be approximately the right frequency (the scope auto frquency measurement claims 2.33 Mhz)
  • [17:14:50] <sakoman_> rise time is roughly 100ns
  • [17:15:36] <sakoman_> fall time around 60ns
  • [17:16:20] <sakoman_> spec for high speed mode is 80ns rise/fall
  • [17:16:48] <sakoman_> so we are on the hairly edge given accuracy I can get from my scope
  • [17:17:37] <sakoman_> Just for completeness I'll disable the internal pullups and see what changes
  • [17:18:47] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) Quit ("Leaving.")
  • [17:29:14] <paul_pwsan> sakoman_: sounds good. may not be a high-speed issue tho since ppl are seeing problems at 400KHz
  • [17:30:21] <sakoman_> paul_pwsan: indeed. 400 works for me, so it is quite puzzling what is going on
  • [17:30:44] <sakoman_> I just wanted to verify with my own eyes that signals were ok
  • [17:31:03] <paul_pwsan> yeah, am happy that you are :-)
  • [17:31:32] <paul_pwsan> in some beagle boots, i get transmit overflow warnings from the i2c-omap driver
  • [17:31:32] <sakoman_> The fact that they are marginal at 2600 and my board is flakey at 2600 gives me some comfort that reality matches theory
  • [17:32:00] <sakoman_> And the fact that at 400 it is in spec and my board also works is also comforting
  • [17:32:02] <paul_pwsan> sounds like beagle should definitely not be running I2C1 at 2.6MHz
  • [17:32:22] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [17:32:35] <sakoman_> What is not comforting is the fact that other folks are seeing issues at 400
  • [17:32:42] <paul_pwsan> yes, including myself
  • [17:32:51] <sakoman_> Those are the boards that will be really interesting to probe
  • [17:33:07] <paul_pwsan> (btw this is rev b4 here)
  • [17:33:40] <paul_pwsan> the transmit overflow messages cause me to wonder if i2c to the twl is taking longer than expected...
  • [17:34:57] <paul_pwsan> the message implies that there is some sort of fifo for i2c transactions, so perhaps i2c-omap needs to have some explicit barriers in there to wait for the fifo to drain
  • [17:35:03] <paul_pwsan> but
  • [17:35:22] <paul_pwsan> if it is primarily a software issue, i am baffled as to why the 3430sdp seems to experience none of this
  • [17:35:43] <paul_pwsan> anyway, just speculation
  • [17:36:10] <sakoman_> paul_pwsan: I don't see these i2c issues on my 35xx EVM either
  • [17:36:19] <paul_pwsan> the zoom? good to know
  • [17:36:27] <sakoman_> no the Mistral EVM
  • [17:36:33] <paul_pwsan> ok
  • [17:36:55] <sakoman_> OK, with internal pullups turned off the signals look a little worse
  • [17:37:33] * lgentili (i=be88a641@gateway/web/ajax/mibbit.com/x-7549a83b748c4dde) has joined #beagle
  • [17:39:12] <sakoman_> rise time a little over 100ns, fall is still around 60ns (which I would expect)
  • [17:39:54] <sakoman_> signal is much "rounder" on the rising edge (again as expected)
  • [17:40:01] * lgentili (i=be88a641@gateway/web/ajax/mibbit.com/x-7549a83b748c4dde) has left #beagle
  • [17:41:53] <sakoman_> So I guess the summary from my perspective is that the signal looks marginal at 2600, but well within spec at 400
  • [17:42:29] <sakoman_> And with internal pullups disable it is even more marginal at 2600, but still OK at 400
  • [17:42:48] * dirk2 (n=dirk@F3258.f.strato-dslnet.de) has left #beagle
  • [17:43:53] <paul_pwsan> am a little concerned that it could be a more systemic problem with beagle, given those x-loader ecc errors
  • [17:44:32] <paul_pwsan> sakoman_: sounds like we should put in a patch to configure beagle i2c1 for 400KHz for the time being...
  • [17:44:48] <sakoman_> Agreed. I by no means believe that we have gotten to the bottom of the issue
  • [17:45:14] <sakoman_> We're just ticking off the potential problem areas one at a time
  • [17:45:59] <sakoman_> It would be good for someone with a board that doesn't work reliably at 400 to check their signal quality ;-)
  • [17:46:31] <sakoman_> Just to see whether the signals are in spec
  • [17:46:45] <paul_pwsan> if i have the opportunity later today, will check it out here
  • [17:47:54] <sakoman_> Your scope will need quite a hefty delay to catch the high speed portion of the transaction
  • [17:49:29] <paul_pwsan> sakoman_: do you recall what your trigger holdoff delay was?
  • [17:50:06] <sakoman_> hmm . . . I had it set at 100ns/div with a delay of 260 div
  • [17:50:47] <ds2> which kernel are people using when this problem occurs?
  • [17:51:06] <paul_pwsan> sakoman_: cool, thank you
  • [17:51:30] <paul_pwsan> here, am using linux-omap git head with the I2C race patch
  • [17:51:49] <paul_pwsan> was -rc9 yesterday
  • [17:51:54] <ds2> let me ask it in a different way - has this problem been observed with the WTBU kernel
  • [17:51:59] <sakoman_> ds2: I'm using the latest git with and without i2c race patch
  • [17:52:38] <paul_pwsan> haven't tried
  • [17:53:07] <ds2> sakoman: I think you said you saw it on the EVM too?
  • [17:53:31] <jkridner|work> is there a simple test-case I can run to show the poor signal quality?
  • [17:53:37] <sakoman_> ds2: extremely rarely, i.e. less than once a month
  • [17:54:03] <jkridner|work> what baffles me is that we have I2C test cases in the manufacturing.
  • [17:54:25] <sakoman_> jkridner|work: just get a good scope and probe the two i2c-1 signals
  • [17:54:59] <jkridner|work> what should I run on the board x-load/u-boot/uImage wise?
  • [17:55:00] <ds2> I have not seen an I2C problem with the beagle but I am using a hybrid kernel
  • [17:55:20] <ds2> it almost seems like some magic is missing in the omap-git tree
  • [17:55:43] <sakoman_> After setting up the trigger conditions (negative slope, .9V, single) I start playing an mp3 in order to generate some i2c traffic
  • [17:56:01] <ds2> eh? why would starting a MP3 generate I2C traffic?
  • [17:56:13] <ds2> are you modulating it via the volume controls?
  • [17:57:05] <sakoman_> ds2: I'm using essentially the same kernel on the EVM. Also I believe the rare EVM i2c errors I saw might be fixed by yesterdays i2c race patch
  • [17:57:25] <sakoman_> ds2: yes, it configures the codec in the 3040
  • [17:57:55] <sakoman_> generates a small handfull of i2c traffic
  • [17:58:04] <ds2> sakoman_: hmmm that shouldn't be much I2C traffic
  • [17:58:11] <sakoman_> it isn't
  • [17:58:19] <ds2> 'k
  • [17:58:21] <sakoman_> but is is enough to capture a signal trace
  • [17:58:42] <sakoman_> fine for measuring frequency and signal rise/fall times
  • [17:59:01] <ds2> ah different test. thought you wanted to trigger the problem
  • [17:59:37] <sakoman_> no, just checking signal quality
  • [18:00:06] <paul_pwsan> ds2: i don't think anyone has isolated a 100% repeatable way to cause the problems in software
  • [18:00:25] <sakoman_> for me, slowing down to 400 eliminates the i2c issues, for others, sadly not
  • [18:00:39] <ds2> paul_pwsan: unless I missed something, isn't it most common during boot?
  • [18:01:15] <paul_pwsan> jkridner|work: surprised that manufacturing test is not seeing the x-loader ECC errors - those are quite frequent here and immediately fatal
  • [18:01:18] <sakoman_> ds2: first shows up there, and does seem to be "sticky" i.e. once bad you are screwed
  • [18:01:40] <ds2> sakoman_: even after a power cycle?
  • [18:01:47] <paul_pwsan> ds2: yes, they show up early in boot
  • [18:01:47] <sakoman_> that would add some weight to your theory that some "magic" is missing in sw
  • [18:02:02] <sakoman_> ds2: power cycle usually fixes it
  • [18:02:04] <paul_pwsan> i haven't been doing any further post-boot testing
  • [18:02:12] <ds2> Hmmm
  • [18:02:30] <ds2> if I have time, I'll build a pure omap-git kernel and see
  • [18:02:30] <jkridner|work> paul_pwsan: did you re-flash x-loader?
  • [18:03:09] <sakoman_> jkridner|work: I did on mine (with khasim's nand support version)
  • [18:03:12] <paul_pwsan> jkridner|work: no, using stock x-loader, u-boot that came with the board. apparently sakoman, koen have been seeing similar problems
  • [18:03:15] <jkridner|work> I'm probably rehashing old ground checking if you used the hw ecc.
  • [18:03:37] <jkridner|work> how do I reproduce?
  • [18:03:38] <sakoman_> jkridner: yes, used 1.1.4 to flash my xloader
  • [18:04:06] <ds2> jkridner: rehashing old territory or you suspect there is a ground issue relating to the need for hardware ecc?
  • [18:04:09] <sakoman_> I think using the wrong ecc would be a 100% failure mode though, right? Not a 5% issue
  • [18:04:21] <jkridner|work> boards are now shipping and being flashed with uboot 1.3.3. (paul's board)
  • [18:04:38] <jkridner|work> the sources used are on code.google.com.
  • [18:05:15] <paul_pwsan> jkridner|work: just reboot board until messages appear. haven't found any pattern to when they appear. messages here: http://pastebin.com/m4789623c
  • [18:05:19] <ds2> i.e. bad pin/solder joint/routing
  • [18:05:45] <jkridner|work> in u-boot, does 'iprobe' work reliably?
  • [18:06:04] <paul_pwsan> btw those pastebin messages are from several separate boots, not all one session.
  • [18:07:02] <sakoman_> jkridner|work: yes it does for me. but I would expect that. u-boot sets up i2c at 100Khz which is extremely forgiving timing-wise
  • [18:07:50] <sakoman_> jkridner|work: If you recall Paul is seeing the same issue that I mentioned a week or two ago
  • [18:08:09] <paul_pwsan> jkridner|work: running iprobe now
  • [18:08:27] <sakoman_> Remember my board got stuck in that mode for the better part of a day (ecc errors every boot attempt)
  • [18:09:05] <sakoman_> Then it mysteriously healed itself and the problem turned back into a 1-5% of boots issue
  • [18:09:55] <sakoman_> And it remains that way, I still get a few of those each day, always solved by a power cycle
  • [18:10:05] <jkridner|work> k. the ECC problem shown by paul_pwsan has shown up for users intermittently. I do remember this. I thought all of the signs were pointing to this being related to a flashing process issue.
  • [18:10:18] <paul_pwsan> jkridner|work: ran iprobe eight times from u-boot. seems to work okay, but obviously have not done intensive testing
  • [18:10:54] <paul_pwsan> i did note that koen apparently reported i2c problems at 100KHz recently
  • [18:11:00] <jkridner|work> k. from sakoman_'s comment, it isn't much of a test. I'm trying to get something simple I can do when I put the boards I've got under the scope.
  • [18:11:44] <sakoman_> jkridner|work: the simplest I found was to just play a sound
  • [18:11:54] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [18:12:13] <sakoman_> I use mplayer
  • [18:12:20] <jkridner|work> with the ALSA drivers in the WTBU kernel?
  • [18:12:36] * JuanG (n=Juan@nat/ti/x-3fd45878bb67becd) has joined #beagle
  • [18:12:40] <sakoman_> I'm using git kernel and OE rootfs
  • [18:12:43] <jkridner|work> (typical vendor response to use their software)
  • [18:13:05] <sakoman_> I assume it work the same with WTBU kernel
  • [18:13:28] <sakoman_> the codec still needs to get set up, so i2c transactions are required
  • [18:14:11] <paul_pwsan> jkridner|work: cdp12.17 does use an older rev of the i2c-omap driver. but if it was strictly a software issue, i would expect to see problems with 3430sdp and evm. both of those seem to run fine with git-head
  • [18:14:12] <sakoman_> You can substitute anything that you know will result in communication with the 4030
  • [18:14:41] <jkridner|work> can I just pull images for testing from http://www.sakoman.net/omap3/beagle/ ?
  • [18:15:30] <sakoman_> most recent are at: http://www.sakoman.net/feeds/omap3/glibc/images/beagleboard/
  • [18:16:23] <sakoman_> I've been using the omap3evm-demo-image-beagleboard in my testing
  • [18:16:41] <sakoman_> it includes mplayer in the image
  • [18:17:19] <sakoman_> For some reason I've never been able to get Beagleboard-demo-image to work on my board
  • [18:18:24] <sakoman_> Part of my bad beagleboard karma
  • [18:19:32] <sakoman_> jkridner|work: I really don't see any reason why you couldn't use the TI images to look at signal quality
  • [18:24:53] <ds2> I think the i2c code supports a userland i2c program to start transactions, maybe that could be the test tool?
  • [18:25:48] * walter_ (n=walter@host121.natpool.mwn.de) has joined #beagle
  • [18:26:05] <paul_pwsan> wonder if the x-loader ECC issue is a NAND timing problem.
  • [18:27:46] <paul_pwsan> jkridner|work, do you know if beagle and evm use the same POP memory part?
  • [18:33:33] * scott_w_ (n=scott@89.240.129.49) has joined #beagle
  • [18:35:03] * scott_w_ is now known as scott_w
  • [18:36:27] <BThompson> beagle and the mistral evm do not necessarily use the same part, depends on what version of the EVM you have
  • [18:40:58] * scott_w (n=scott@89.240.129.49) has left #beagle
  • [18:45:07] <paul_pwsan> btw jkridner|work, re I2C analog testing and WTBU kernel. i don't know what kernel "WTBU kernel" refers to, but just fyi, it appears that the i2c-omap driver in cdp12.17 does not support I2C > 400KHz. so you will probably have to use l-o
  • [18:46:04] <ds2> eh? hmmm
  • [18:46:12] <jkridner|work> the beagle kernel linked by code.google.com is based on cdp12.14, I believe.
  • [18:47:24] <ds2> indeed
  • [18:47:58] <paul_pwsan> i'm sorry. i take that back.
  • [18:48:17] <paul_pwsan> cdp12.14 and 12.17 both do support high speed -- looked at wrong file
  • [18:49:25] <ds2> they dont' do it in the boardfile?
  • [18:49:29] <paul_pwsan> too many kernels :-(
  • [18:50:19] <paul_pwsan> drivers/i2c/busses/i2c-omap.c is where the registers are programmed - OMAP_I2C_CON_OPMODE_HS
  • [19:00:12] <Crofton> sakoman, http://rafb.net/p/bmm4TD75.html
  • [19:00:32] <Crofton> to reproduce, opkg install gnuradio
  • [19:00:39] <paul_pwsan> Crofton: is that with the i2c patch i posted yesterday to l-o?
  • [19:00:51] <Crofton> then python /usr/share/gnuradio/examples/audio/dial_tone.py
  • [19:00:54] <Crofton> no
  • [19:00:58] <paul_pwsan> Crofton: try that
  • [19:01:05] <Crofton> heh
  • [19:01:12] <Crofton> tomorrow
  • [19:01:40] <Crofton> I am doing a test against an image I built with libusb 0.1.12 today
  • [19:01:51] <Crofton> it recovers from this :)
  • [19:01:52] <paul_pwsan> does it happen consistently?
  • [19:01:56] <Crofton> not sure
  • [19:02:07] <Crofton> I just ran this example to see what happened
  • [19:02:10] <paul_pwsan> k
  • [19:02:47] <Crofton> every now and then I get i2c timeouts, but it recovers
  • [19:03:10] <ds2> is arch/arm/configs/omap3_beagle_defconfig a good config for the omap-git tree?
  • [19:03:24] * esden is now known as esden`away
  • [19:03:25] <paul_pwsan> thats what i use here
  • [19:03:30] <ds2> 'k
  • [19:03:51] <paul_pwsan> Crofton: hopefully that is fixed by http://marc.info/?l=linux-omap&m=121614853008185&w=2 , but who knows...
  • [19:04:04] <paul_pwsan> haven't seen it recur after that patch applied here
  • [19:05:23] <sakoman_> Crofton: agreed, that looks like precisely the symptom fixed by Paul's patch
  • [19:05:44] <Crofton> grrr
  • [19:06:12] * Crofton hopes I have the same usrp + usb issue with the old libusb ....
  • [19:06:19] <sakoman_> It just got triggered by the audio i2c transactions
  • [19:06:32] <Crofton> good
  • [19:06:54] <Crofton> do you know if koen added that to the OE kernel build?
  • [19:08:03] <sakoman_> I believe so
  • [19:10:55] <Crofton> frack
  • [19:11:06] <Crofton> libusb-0.1.12 works
  • [19:11:19] <Crofton> xfered 1.34e+08 bytes in 19 seconds. 7.07e+06 bytes/sec. cpu time = 0.4141
  • [19:11:25] <Crofton> not as fast as a pc
  • [19:11:35] <Crofton> and it hung
  • [19:11:45] <Crofton> but, it sort of worked .....
  • [19:15:07] * RogerMonk (n=a0740758@nat/ti/x-b9b340259da44b6f) Quit (Remote closed the connection)
  • [19:24:45] <Crofton> ah managed to get an ooops!
  • [19:24:47] <Crofton> http://rafb.net/p/hVtBDP73.html
  • [19:25:07] <Crofton> does that make sense to anyone?
  • [19:31:54] <paul_pwsan> Crofton, just a wild guess, but it looks like usb_hcd_flush_endpoint() tried to use an URB that should have been already freed (when its refcount went to 0). looks like it happened when the program was exiting.
  • [19:35:53] <Crofton> yes, it is exiting
  • [19:35:59] <Crofton> any idea how to fix this?
  • [19:37:06] <Crofton> or where to post so the right people see it
  • [19:37:45] <paul_pwsan> try linux-usb@vger.kernel.org
  • [19:37:55] <Crofton> ok
  • [19:39:34] <koen> Crofton: I just forwarded you a patch from felipe for musb
  • [19:39:59] <Crofton> koen, my headache atm is I can't use libusb1
  • [19:40:05] <Crofton> with the usrp
  • [19:40:42] <koen> Crofton: I didn't test that because I lack an usrp
  • [19:40:44] <Crofton> I have hacked out the libusb1 stuff
  • [19:41:29] <Crofton> can we set things up so we can easily move between libusb and libusb-compat?
  • [19:42:13] * MRoumbakis (n=mroumbak@nat/ti/x-6defe2b1ab5d2a16) has joined #beagle
  • [19:43:16] <Crofton> I'm going to revert the libusb1 removal and rebuild tonight
  • [19:43:21] * MRoumbakis is now known as mroumbakis
  • [19:43:47] <Crofton> the gnuradio dailtone.py example triggered a sound problem
  • [19:44:16] <Crofton> do you have a board with the i2c patch in? could you check dialtone.py?
  • [19:44:30] <koen> Crofton: we can't switched easily since libusbcompat pretends to be libusb
  • [19:44:41] * Crofton grumbles
  • [19:44:46] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has joined #beagle
  • [19:44:46] <koen> my beagle gear is all packed
  • [19:44:51] <koen> (the serial cable)
  • [19:44:51] <Crofton> ah
  • [19:44:55] <Crofton> have a good trip
  • [19:45:06] <Crofton> I can check, it will just take time
  • [19:45:10] <koen> getting up and *$(*@#$(@# 4 in the morning
  • [19:45:16] <Crofton> heh
  • [19:45:17] <koen> s/and/at/
  • [19:46:36] <paul_pwsan> hmmm
  • [19:47:08] <paul_pwsan> has anyone else out there with beagles noticed a relatively rare hang after "Calibrating delay loop..." ?
  • [19:47:19] <paul_pwsan> happened probably two or three times to me so far
  • [19:47:42] <koen> not that I can remember, but I'm booting with debug_ll off
  • [19:47:54] <paul_pwsan> ok
  • [19:48:16] <koen> I do see hangs with onl "uncompressing....." on serial, so that could be it
  • [19:49:46] * JoeBorn (n=jborn@adsl-75-3-7-18.dsl.chcgil.sbcglobal.net) Quit (Read error: 110 (Connection timed out))
  • [19:54:56] <sakoman_> paul_pwsan: haven't seen that one on either beagle or evm
  • [19:56:48] <paul_pwsan> sakoman_: do you compile with CONFIG_DEBUG_LL enabled?
  • [19:57:45] <sakoman_> paul_pwsan: # CONFIG_DEBUG_LL is not set
  • [19:58:12] <paul_pwsan> k. it would look like it hangs after "Uncompressing.." then, per koen (thx koen for the reminder...)
  • [19:59:20] <sakoman_> IIRC, banderson was looking into hangs after "Uncompressing"
  • [20:06:40] <banderson> The hangs I saw after the Uncompressing have been traced to i2c errror. If the evm sees a i2c error and I do a warm reset then I will get a hang (that can only be seen if you enable config_debug_LL).
  • [20:07:20] <banderson> It always hangs in same spot where it is waiting for a i2c register bit to flip ...but evidently it never does...
  • [20:08:12] <paul_pwsan> banderson: i think i've seen those too with beagle. do you know what function/line number it hangs in?
  • [20:08:24] <banderson> yes let me look it up again...
  • [20:11:09] <banderson> I really need to take time and get oe setup "correctly"
  • [20:13:16] * JuanG (n=Juan@nat/ti/x-3fd45878bb67becd) has left #beagle
  • [20:20:43] * mroumbakis (n=mroumbak@nat/ti/x-6defe2b1ab5d2a16) Quit ()
  • [20:21:07] <banderson> drivers/i2c/busses/i2c-omap.c: omap_i2c_xfer_msg() (line 438 for me) Otherwise just look for the line " Dont do anything - this will come in a couple of loops at max "
  • [20:23:30] <paul_pwsan> thanks banderson. heh, that is an awesome comment.
  • [20:25:21] <banderson> paul_pwsan: I stuck a counter in there that when it expired it would exit and call the same omap_i2c_init() function that it does on controller timeouts. Unfortunatly that just resulted in infinite loop of "controller timed out" messages...
  • [20:26:55] <paul_pwsan> i wonder if the mask rom is not resetting the I2C controller
  • [20:27:55] <paul_pwsan> hmm, it looks like omap_i2c_init() tries to reset it itself
  • [21:10:55] * RogerMonk (n=a0740758@nat/ti/x-7943bd485f0222f1) has joined #beagle
  • [21:18:56] * BThompson (n=BThompso@nat/ti/x-57502b259608246d) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [21:24:36] * docelic (n=docelic@78.134.201.183) Quit ("http://www.spinlocksolutions.com/")
  • [21:28:26] * walter_ (n=walter@host121.natpool.mwn.de) Quit (Read error: 104 (Connection reset by peer))
  • [21:29:04] * bazbell (n=a0192809@nat/ti/x-2c61d30a337b9340) Quit (Remote closed the connection)
  • [21:31:03] * dschaeffer (n=daniel@timesys-gw0.cust.expedient.net) has left #beagle
  • [21:41:48] <paul_pwsan> hmmm...
  • [21:42:08] <paul_pwsan> also have seen a few hangs in X-loader after "Starting OS Bootloader..."
  • [21:47:45] * RogerMon1 (n=a0740758@nat/ti/x-116c8f00c7b28d2e) has joined #beagle
  • [21:50:53] <sakoman_> paul_pwsan: I see those occasionally, too
  • [21:55:00] * RogerMonk (n=a0740758@nat/ti/x-7943bd485f0222f1) Quit (Remote closed the connection)
  • [21:55:16] * prpplague (n=dave@mail.americanmicrosystems.com) Quit ("Leaving")
  • [22:02:06] <Crofton|work> crap, I am making an idiot of myself
  • [22:02:09] <Crofton|work> such is life
  • [22:03:56] <sakoman_> Crofton: we wouldn't have known if you didn't tell us :-)
  • [22:11:31] <paul_pwsan> oookay
  • [22:12:05] <paul_pwsan> here's a patch that seems to get rid of the I2C irq 368 disabled, but unmaskable problems
  • [22:12:19] <paul_pwsan> would appreciate any help testing...
  • [22:12:24] <paul_pwsan> http://www.pwsan.com/omap/read_write_twl4030_isrs_to_clear.patch
  • [22:13:08] <paul_pwsan> turns out that we probably weren't clearing twl4030 interrupt status bits properly during init
  • [22:13:09] <mru> is that i2c bus speed change meant to be in there?
  • [22:13:12] * Beagle4 (n=Beagle4@cpc1-popl1-0-0-cust495.popl.cable.ntl.com) has joined #beagle
  • [22:13:17] <paul_pwsan> yeah, per sakoman
  • [22:13:24] <paul_pwsan> it's not meant for merging.
  • [22:13:29] * mickeyl is now known as mickey|zzZZzz
  • [22:13:31] <paul_pwsan> this particular patch, that is.
  • [22:14:09] <paul_pwsan> apparently 2.6MHz I2C is marginal on some, maybe all beagles..
  • [22:14:34] <mru> I don't usually see any i2c error messages
  • [22:14:40] <paul_pwsan> lucky you!
  • [22:14:49] <paul_pwsan> i get them almost every boot
  • [22:14:50] <mru> occasionally I get a flood of messages and booting fails
  • [22:15:08] <mru> a hard power cycle is usually required when it happens
  • [22:15:16] <paul_pwsan> doesn't help here
  • [22:15:26] <paul_pwsan> but apparently it helps koen too
  • [22:15:29] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [22:16:15] <paul_pwsan> i still see other problems with other subsystems during booting. the big offender now on my beagle is omapfb
  • [22:16:55] <paul_pwsan> aside from the random freezes, of which there are quite a few...
  • [22:18:39] <paul_pwsan> still baffled though why this problem would not affect 3430sdp. maybe it is using a different twl4030 revision?
  • [22:19:39] <paul_pwsan> typical omapfb problems here look like this: http://pastebin.com/m39541688
  • [22:19:49] <paul_pwsan> would enjoy knowing if anyone else is encountering these
  • [22:20:13] * Beagle4 (n=Beagle4@cpc1-popl1-0-0-cust495.popl.cable.ntl.com) Quit ()
  • [22:20:26] <mru> I've seen those on occasion
  • [22:20:37] <mru> what makes you think they're omapfb related?
  • [22:20:57] <paul_pwsan> they only seem to appear in tandem with the omapfb irq error status messages
  • [22:21:14] <paul_pwsan> if the omapfb irq errors do not appear, the irq -33 messages don't either, on this beagle anyway
  • [22:21:22] <mru> I don't recall seeing the omapfb irq error messages
  • [22:21:30] <mru> but then I may have missed them
  • [22:21:40] <mru> the irq -33 messages quickly fill my console
  • [22:21:45] <paul_pwsan> yeah same here
  • [22:22:17] <mru> it hasn't happened in a while though
  • [22:23:03] <paul_pwsan> happens about once every 10 or 15 boots here, would estimate
  • [22:26:47] <mru> I only reboot mine every few days
  • [22:26:54] <mru> when not doing kernel hacking
  • [22:27:30] <paul_pwsan> mru, are you using the linux-omap kernel, or the wtbu kernel?
  • [22:27:39] <mru> linux-omap
  • [22:27:45] <mru> with some hacks of my own
  • [22:27:57] <paul_pwsan> k
  • [22:29:58] <paul_pwsan> mru, do you generally use serial console or something over ethernet?
  • [22:30:39] <paul_pwsan> or usb keyboard/omapfb, i guess...
  • [22:31:14] <mru> serial
  • [22:31:29] <paul_pwsan> wow
  • [22:31:35] <mru> it's the most reliable
  • [22:31:45] <paul_pwsan> usually serial console here becomes unresponsive within a few commands
  • [22:31:53] <mru> that's my usb
  • [22:32:07] <paul_pwsan> doh
  • [22:32:44] <mru> any sustained traffic seems to kill it
  • [22:45:50] <paul_pwsan> mru, noticed this recently: http://git.mansr.com/?p=linux-omap;a=blobdiff;f=arch/arm/mach-omap2/clock34xx.c;fp=arch/arm/mach-omap2/clock34xx.c;h=04dedecf5ef49e826df9a882ce50a700b0b76aad;hp=8fdf8f3c09fb0fb62911346d0a47088c2d4674f0;hb=d23f9c3c5c6243b626f7ec4c255469de2536e488;hpb=2929b75035ebe8702ba2ff2c81b654c487701f64
  • [22:46:19] <paul_pwsan> just out of curiosity, what rate are you setting dss1_alwon_fclk to?
  • [22:50:05] <mru> iirc, that setting gives 432 MHz
  • [22:59:08] <jkridner|work> sakoman: are you really using serial to copy the JFSS2 image over?
  • [22:59:09] <sakoman_> paul_pwsan: yes it gives 432 Mhz I set that in u-boot also
  • [22:59:15] <jkridner|work> er, JFFS2.
  • [22:59:41] <jkridner|work> I was trying to install your u-boot, kernel, and file system to see what the I2C signals look like in that case.
  • [23:00:08] <sakoman_> jkridner: no, I used to use mmc
  • [23:00:31] <jkridner|work> I use an SD card to transfer the files, but the JFFS2 file transfer to the board either takes a REALLY long time or is hanging.
  • [23:00:33] <sakoman_> but now I don't bother because OE generated jffs2 images don't work with nand
  • [23:00:59] <jkridner|work> do you just put the file system on an SD?
  • [23:01:29] <sakoman_> For beagle you have to use sd till I figure out what is broken between OE and nand
  • [23:01:58] <sakoman_> I should update those flash instructions
  • [23:02:08] <sakoman_> I forget that people actually use them!
  • [23:02:59] <jkridner|work> I find them really handy because I like to follow some guide to avoid missing steps (because I get a lot of distractions).
  • [23:04:57] <jkridner|work> I'm getting a bunch of those I2C timeouts that I don't normally get with the kernels I'm using.
  • [23:05:35] <paul_pwsan> jkridner|work: perhaps try http://www.pwsan.com/omap/read_write_twl4030_isrs_to_clear.patch
  • [23:06:47] <jkridner|work> with that patch, are you still getting the I2C failures?
  • [23:07:19] <jkridner|work> Gerald has interpreted I2C failures as a production stop issue on Beagle and that is what I'm trying to address. I want to see the failures to diagnose them.
  • [23:08:10] <paul_pwsan> with that patch, and the irq 56 patch posted the other day, I2C failures no longer dominate my boots.
  • [23:08:11] <sakoman> jkridner: I did a quick update on the flash instructions
  • [23:08:14] <jkridner|work> sakoman_: with an OE file system, what is the easiest way to get the desired I2C traffic.
  • [23:08:17] <sakoman> will do a few more
  • [23:09:15] <jkridner|work> I don't believe noinitrd is useful.
  • [23:09:29] <jkridner|work> rootfstype may speed detection, but is not required.
  • [23:09:33] <Crofton> Did we decide some of the alsa issues where from i2c?
  • [23:09:39] <sakoman_> OK, I'll make it disappear
  • [23:10:17] <Crofton> tomorrow I'm going to run the current OE build and run the gnuradio audio demo
  • [23:10:39] <jkridner|work> strange, I just got a serial hang-up. I don't get that on the code.google.com kernel.
  • [23:10:48] <Crofton> and the dsplink samples on the sffsdr board
  • [23:10:56] <mru> my beagle has decided to crash a lot today
  • [23:11:09] <Crofton> then I need to reproduce my usb issue with logging on
  • [23:11:11] <sakoman_> jkridner: that is a linux-omap git bug that only seems to show up on beagle
  • [23:11:12] <mru> probably because the demo is getting close
  • [23:11:20] <Crofton> mru, right :)
  • [23:11:28] <jkridner|work> :)
  • [23:11:43] <paul_pwsan> jkridner|work: in fact i haven't had any I2C failures at all in 30+ reboots, which is a new record for this beagle
  • [23:11:47] <sakoman_> jkridner: I just play an mp3 to generate i2c transactions
  • [23:11:52] * Crofton has too many different threads going atm, he needs to finish some
  • [23:11:57] * bazbell (n=a0192809@nat/ti/x-31c81c253db7dcec) has joined #beagle
  • [23:12:21] <mru> and it's crashing in the most annoying of ways
  • [23:12:28] <mru> that is, it just stops dead
  • [23:12:33] <mru> no messages anywhere
  • [23:12:44] <paul_pwsan> mru: does sysrq-p work?
  • [23:12:52] <mru> no keyboard
  • [23:12:55] <jkridner|work> which player and what arguments?
  • [23:12:58] <paul_pwsan> try sending break + p
  • [23:13:06] <sakoman_> mplayer song.mp3
  • [23:14:18] <paul_pwsan> nice. i'm going to go out on a limb and say that the i2c failures don't show up at all with irq56 patch + read_write_isr patch + 400KHz I2C1.
  • [23:14:29] <paul_pwsan> about 40 reboots now.
  • [23:16:12] <paul_pwsan> will test to see if cranking I2C1 back up to 2.6MHz here changes anything.
  • [23:18:37] <mru> I'm collecting some video clips to use for the demo
  • [23:18:38] <sakoman_> paul_pwsan: with 400Khz + your irq56 patch I have seen no i2c issues at all
  • [23:18:45] <jkridner|work> urgh. I really wanted to look at this before I went home because I don't have a scope at home, but I don't have mplayer on the OE file system I'm running.
  • [23:19:02] <mru> good suggestions are welcome
  • [23:19:03] <paul_pwsan> sakoman_: thats great!
  • [23:19:11] <paul_pwsan> but weird
  • [23:19:16] <sakoman_> jkridner: just use anything that plays sound
  • [23:19:27] <paul_pwsan> that i see so many irqs on boot...
  • [23:19:33] <paul_pwsan> irq problems on boot that is
  • [23:19:40] <sakoman_> change volume if you have a settings tool
  • [23:19:58] <sakoman_> paul_pwsan: I don't get those now.
  • [23:20:03] <paul_pwsan> the two TWL4030 IRQs that i've been seeing have been the GPIO0 IRQ, and the RTC_IT IRQ
  • [23:20:09] <sakoman_> this is really strange
  • [23:20:22] <paul_pwsan> with the read_write_isr patch, those are gone
  • [23:20:29] <sakoman_> we all see i2c related stuff but with varying severity
  • [23:20:32] <paul_pwsan> yeah
  • [23:20:54] <paul_pwsan> done about 10 reboots here with I2C1 at 2.6MHz with no problems
  • [23:21:20] <sakoman_> I will try your new patch at 2.6 and see what happens
  • [23:21:50] <paul_pwsan> should be completely unrelated, but who knows at this point
  • [23:23:47] <paul_pwsan> btw, in case it is useful, i boot from sd and use serial console. nothing else connected, except a pair of headphones for the boot bleep
  • [23:24:14] <paul_pwsan> er. excuse me.
  • [23:24:21] <paul_pwsan> x-loader and u-boot are from nand.
  • [23:24:29] <paul_pwsan> but rootfs is on sd.
  • [23:24:46] <paul_pwsan> xloader is 1.41. u-boot is 1.3.3-00035-gab55ae5-dirty (Jun 16 2008 - 17:35:22)
  • [23:25:53] <sakoman_> paul_pwsan: almost same here: xloader, u-boot, and uImage in nand, rootfs in SD
  • [23:26:14] <sakoman_> u-boot is 1.3.4rc1 from my git
  • [23:27:03] <sakoman_> Only connections are serial port, power, and headphones
  • [23:27:33] <sakoman_> (and occasionally a couple of scope probes)
  • [23:28:06] <sakoman_> kernel is 2.6.26 from my git
  • [23:29:54] <paul_pwsan> okay, in terms of I2C, 35 boots with 2.6MHz I2C1 all work fine here on this rev B4. Got a few other failures: omapfb random hangs (6/35), x-loader ECC failures (2/35), and random hangs after init starts (1/35)
  • [23:32:16] <paul_pwsan> haven't tried playing music.
  • [23:34:25] <jkridner|work> I'm seeing really clean 400kHz I2C signals on R11. 200ns fall time and 60ns rise time.
  • [23:36:01] <sakoman_> jkridner: what bandwidth on your scope?
  • [23:36:34] <paul_pwsan> sakoman_, it was the 2.6MHz I2C that failed your test, right?
  • [23:37:01] <sakoman_> yes, the 2.6 Mhz looked marginal on my scope
  • [23:37:08] <jkridner|work> I have a 500MHz (2Gs/s) scope.
  • [23:38:04] <paul_pwsan> sakoman_, do you have the OE image that you're booting from posted? will try that here if so at 2.6MHz
  • [23:38:07] <jkridner|work> Do we think the only problem is at 2.6MHz?
  • [23:39:47] <sakoman_> jkridner: I saw 80ns rise, 200ns fall on 400Khz
  • [23:40:00] <sakoman_> spec is < 300ns for 400Khz
  • [23:40:15] <sakoman_> so we are fairly close in our measurements
  • [23:40:42] <paul_pwsan> sakoman_: found it in IRC history...
  • [23:41:33] <sakoman_> jkridner: your scope is better than mine so your numbers will likely be more accurate
  • [23:41:39] <jkridner|work> the thing I'm struggling with is if there is a manufacturing issue.
  • [23:42:02] <jkridner|work> what we don't want is to have a bunch of boards out there that we have to collect back for repairs/replacements.
  • [23:42:29] <sakoman_> jkridner|work: I really don't know! We are all missing something here
  • [23:42:47] <sakoman_> The strange thing is that we don't see this on the EVM
  • [23:43:00] <jkridner|work> but something is pointing to board-specific dependencies, even at 400kHz?
  • [23:43:05] <banderson> ahhmmmmm :)
  • [23:43:14] <banderson> some of us don't...
  • [23:43:30] <sakoman_> oops! How could I have forgotten!
  • [23:43:39] <banderson> lol
  • [23:44:06] <jkridner|work> well, I think I'm headed home. It'll take me a couple of hours before I'm ready for the scope again.
  • [23:44:25] <sakoman_> anyway, something is not right. and it could very well be related to linux-omap git vs wtbu
  • [23:44:46] <sakoman_> I need to step away for a couple of hours too
  • [23:44:56] <jkridner|work> I really hate for something like that to prevent people from getting boards--but it would be worse to get boards that are busted.
  • [23:45:35] <sakoman_> If the boards work 10% reliably with wtbu kernel then it sure would point to a sw issue!
  • [23:45:42] <sakoman_> 100% sheesh!
  • [23:45:48] <jkridner|work> I'd be really happy if everyone seeing issues would try the code.google.com x-load, u-boot, and uImage binaries, just to see if that points to differences in the hardware.
  • [23:45:56] <sakoman_> I will do that
  • [23:46:20] <paul_pwsan> well, there are definitely bugs in l-o i2c-omap
  • [23:46:25] <paul_pwsan> at least two :-)
  • [23:46:53] <jkridner|work> thanks. RogerMon1 claims to have done so and seen an I2C-related issue. I think that's why this has blown-up on my end.
  • [23:47:36] <jkridner|work> I'm still hopeful that was a usage issue, rather than test escape.
  • [23:48:21] <jkridner|work> I believe he was having MMC/SD failures related to powering MMC/SD card via I2C commands, but I'm not sure.
  • [23:48:33] <jkridner|work> I'm sure we'll hear from him overnight.
  • [23:48:37] <jkridner|work> off to home.
  • [23:49:42] * jkridner|work (n=a0321898@nat/ti/x-7bbbfc52ad351d88) Quit ("Leaving.")
  • [23:53:56] <paul_pwsan> sakoman_: tried booting your image,
  • [23:54:17] <paul_pwsan> but am running into the same serial problem koen and i were discussing recently
  • [23:54:35] <RogerMon1> (jkridner|work) - a usage issue :) - thanks!
  • [23:54:45] <paul_pwsan> output stops. sysrq-p works
  • [23:55:28] <paul_pwsan> will try your kernel