U-Boot v1
==========
* GCC versions:
I use Steve's uboot for beagle git (test) head [2]. Compiling this
with different CSL toolchains I get uboot I2C timeouts or not:
gcc version 4.2.0 20070413 2007q1-10: No uboot I2C timeouts
gcc version 4.2.1 2007q3-51: No uboot I2C timeouts
gcc version 4.2.3 2008q1-126: uboot I2C timeouts:
-- cut --
U-Boot 1.3.3 (Jun 15 2008 - 15:15:57)
OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle Board + LPDDR/NAND
RAM Configuration:
Bank #0: 80000000 128 MB
Bank #1: 88000000 0 kB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
timed out in wait_for_bb: I2C_STAT=1000
timed out in wait_for_bb: I2C_STAT=1000
timed out in wait_for_bb: I2C_STAT=1000
timed out in wait_for_pin: I2C_STAT=1000
I2C read: I/O error
timed out in wait_for_bb: I2C_STAT=1000
timed out in wait_for_bb: I2C_STAT=1000
Hit any key to stop autoboot: 0
OMAP3 beagleboard.org #
-- cut --
* U-Boot I2C code:
Again at IRC [3], Nishant did some comments on U-Boot v1 I2C code
(thanks!)
"/* have to enable intrrupts or OMAP i2c module doesn't work */ that
is plain dumb.. it seem to work just fine"
"outw (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX, I2C_CON);
=> no required h/w workaround on some i2c revs"
etc.
Then Nishant sent the I2C code he currently uses (cleanup needed) for
his uboot v2 work (see attachment). This seems to be quite different
from current uboot v1 I2C code.
Kernel
======
Using Koen's kernel
I get I2C timeouts, too (using non-timeout uboot):
-- cut --
...
usbcore: registered new interface driver cdc_ether
i2c /dev entries driver
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
TWL4030 GPIO Demux: IRQ Range 384 to 402, Initialization Success
...
-- cut --
Compiling recent OMAP git head beagle defconfig with CSL 2008q1-126
doesn't show any I2C errors. Most probable because no I2C is used? Any
easy kernel I2C test cases?
Nishant's (uboot v2) I2C code in attachment and
drivers/i2c/busses/i2c-omap.c from git kernel are somehow different, too.
Cheers
Dirk
[1] http://www.beagleboard.org/irclogs/index.php?date=2008-06-14#T10:54:03
[2]
http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=shortlog;h=refs/heads/test
[3] http://www.beagleboard.org/irclogs/index.php?date=2008-06-13#T19:17:46
Regards,
Nishanth Menon
Thanks to Nishant's help (thanks!), using i2cdetect with OMAP git
defconfig results in:
# i2cdetect -a -y -r 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU UU UU UU -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
# i2cdetect -a -y -r 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: <3>i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
-- <3>i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
-- <3>i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
-- <3>i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
-- ^C<3>i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
# i2cdetect -a -y -r 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
#
Check pin mux of u-boot v2/kernel which ever. For some reason ( I have an hypothesis), without the proper muxing the timeout will happen. My hypothesis is that without terminating resistors, the i2c controller cannot detect NAK condition on bus, hence timesout.
The proof of concept on SDP3430 -> SDP3430 uses 2 busses ->i2c1 and i2c2. i missed moving my i2c pin mux out of a #define, and well.. I was seeing i2c timeouts in bus2 but not in bus1 no matter which ever speed I try. After ages of kicking myself, I decided to look at my pin mux, and bingo, bus2 started working.. as a test I decided to try i2c3, and it did not work.. so I am guessing I don't have terminating resistors out there/ I goofed up my pin mux for bus3 (yet again)..
But that does seem to show the issue.
Regards,
Nishanth Menon
Okay, yes your are right, it is pin mux. Thanks for this!
Checked with beagle:
At beagle, I2C2 is routed to expansion connector ( [1] page 81, table
18, lines 23 & 24). Alternatively, I2C SDA and SCL can be used as
GPIO's 183 & 168. And this is what recent uboot pin mux configures:
line 637 & 638. I.e. uboot configures GPIO pins and not I2C2.
So we have two options to fix I2C2 timeout issues:
a) Disable I2C2 in uboot and kernel (how to do this?).
b) Configure (without anything at expansion connector: unused) I2C2
and not GPIOs in uboot's pin mux. For this we could use something like
in attachment.
All: What do people think which option should we take?
Dirk
[1] http://www.beagleboard.org/uploads/Beagle_HW_Reference_Manual_A_5.pdf
Okay, yes your are right, it is pin mux. Thanks for this!
Checked with beagle:
At beagle, I2C2 is routed to expansion connector ( [1] page 81, table
18, lines 23 & 24). Alternatively, I2C SDA and SCL can be used as
GPIO's 183 & 168. And this is what recent uboot pin mux configures:
http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=blob;f=include/asm-arm/arch-omap3/mux.h;h=33947b9e8a078d36f43c95a720e1e6279e5e61a4;hb=refs/heads/test
line 637 & 638. I.e. uboot configures GPIO pins and not I2C2.
So we have two options to fix I2C2 timeout issues:
a) Disable I2C2 in uboot and kernel (how to do this?).
b) Configure (without anything at expansion connector: unused) I2C2
and not GPIOs in uboot's pin mux. For this we could use something like
in attachment.
Changing this with below uboot pin mux changes *doesn't* work:
# i2cdetect -a -y -r 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: <3>i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
-- <3>i2c_omap i2c_omap.2: Arbitration lost
i2c_omap i2c_omap.2: Arbitration lost
-- ^C<3>i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
Some additional results from discussion at IRC [1]:
- On EVM a team reported I2C timeout issues on I2C2 and there the I2C2
is connected to a camera module. So at beagle we are not alone with
this issue
- If I2C2 pin mux (pull up) and clocks are correct, there should be
*no* timeouts even if nothing is connected to beagle's expansion
connector (I2C2 unused)
- Khasim proposed to comment the omap_i2c_idle in omap_i2c_xfer in
drivers/i2c/busses/i2c-omap.c (sth like in attachment)
This makes things worse, system crashes already at boot:
-- cut --
...
<3>USB: No board-specific platform config found
<6>i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
<6>i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz
<6>i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
<6>TWL4030: TRY attach Slave TWL4030-ID0 on Adapter OMAP I2C adapter [1]
<6>TWL4030: TRY attach Slave TWL4030-ID1 on Adapter OMAP I2C adapter [1]
<6>TWL4030: TRY attach Slave TWL4030-ID2 on Adapter OMAP I2C adapter [1]
<6>TWL4030: TRY attach Slave TWL4030-ID3 on Adapter OMAP I2C adapter [1]
<1>Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8070008
Internal error: : 1028 [#1]
Modules linked in:
CPU: 0 Not tainted (2.6.26-rc6-omap1-04677-g5b97d3e-dirty #3)
PC is at omap_i2c_xfer+0x78/0x27c
LR is at msecs_to_jiffies+0x28/0x4c
pc : [<c02c7b08>] lr : [<c0197ed0>] psr: 80000013
sp : c7c1de58 ip : 00000000 fp : c7c1de94
r10: c7c1def6 r9 : 00000000 r8 : 00000001
r7 : c044a148 r6 : c7c90600 r5 : c0439f70 r4 : ffff6aa7
r3 : d8070000 r2 : 00000080 r1 : 00000200 r0 : 00000001
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 00c5387f Table: 80004018 DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc7c1c2e0)
...
Backtrace:
[<c02c7a90>] (omap_i2c_xfer+0x0/0x27c) from [<c02c53c8>]
(i2c_transfer+0x88/0x9c)
[<c02c5340>] (i2c_transfer+0x0/0x9c) from [<c02c8938>]
(twl4030_i2c_write+0xc0/0xe8)
r6:00000011 r5:c044a160 r4:c0449ff8
[<c02c8878>] (twl4030_i2c_write+0x0/0xe8) from [<c02c8988>]
(twl4030_i2c_write_u8+0x28/0x30)
[<c02c8960>] (twl4030_i2c_write_u8+0x0/0x30) from [<c02c8aec>]
(twl4030_attach_adapter+0x15c/0x698)
[<c02c8990>] (twl4030_attach_adapter+0x0/0x698) from [<c02c6228>]
(i2c_register_driver+0xa8/0xec)
[<c02c6180>] (i2c_register_driver+0x0/0xec) from [<c001a334>]
(twl4030_init+0x18/0x20)
r7:c001a31c r6:00000000 r5:00000000 r4:c016c000
[<c001a31c>] (twl4030_init+0x0/0x20) from [<c0008934>]
(kernel_init+0xa4/0x240)
[<c0008890>] (kernel_init+0x0/0x240) from [<c0196c10>] (do_exit+0x0/0x5f0)
Code: ea000057 ebfb531c e5963004 e3a00001 (e1d330b8)
<4>---[ end trace 1b75b31a2719ed1c ]---
<0>Kernel panic - not syncing: Attempted to kill init!
-- cut --
[1]
http://www.beagleboard.org/irclogs/index.php?date=2008-06-20#T17:02:03
> ------------------------------------------------------------------------
>
> Index: uboot_beagle/include/asm-arm/arch-omap3/mux.h
> ===================================================================
> --- uboot_beagle.orig/include/asm-arm/arch-omap3/mux.h
> +++ uboot_beagle/include/asm-arm/arch-omap3/mux.h
> @@ -634,8 +634,8 @@
> MUX_VAL(CP(HSUSB0_DATA7), (IEN | PTD | DIS | M0)) /*HSUSB0_DATA7*/\
> MUX_VAL(CP(I2C1_SCL), (IEN | PTU | EN | M0)) /*I2C1_SCL*/\
> MUX_VAL(CP(I2C1_SDA), (IEN | PTU | EN | M0)) /*I2C1_SDA*/\
> - MUX_VAL(CP(I2C2_SCL), (IDIS | PTU | DIS | M4)) /*GPIO_168*/\
> - MUX_VAL(CP(I2C2_SDA), (IEN | PTU | EN | M4)) /*GPIO_183*/\
> + MUX_VAL(CP(I2C2_SCL), (IEN | PTU | EN | M0)) /*I2C2_SCL*/\
> + MUX_VAL(CP(I2C2_SDA), (IEN | PTU | EN | M0)) /*I2C2_SDA*/\
> MUX_VAL(CP(I2C3_SCL), (IEN | PTU | EN | M0)) /*I2C3_SCL*/\
> MUX_VAL(CP(I2C3_SDA), (IEN | PTU | EN | M0)) /*I2C3_SDA*/\
> MUX_VAL(CP(I2C4_SCL), (IEN | PTU | EN | M0)) /*I2C4_SCL*/\
On Jun 25, 2008, at 11:58 PM, sakoman wrote:
>
>
> Our choices seem to be:
>
> 1. Leave the u-boot mux setting for these signals as GPIOs and disable
> the I2C2 channel in the linux board file for beagle. Adjust
> expansion connector docs to reflect this.
I believe this is our best option because it can be applied in
software and will make all boards work. It further provides the most
flexibility to whomever creates an expansion device. Documentation
will need to be updated accordingly.
>
> 2. Fix the u-boot mux settings, live with the timeout errors at boot
> (they will disappear if/when expansion hw with pullups is connected)
This will slow the boot and confuse the user.
>
> 3. Fix the u-boot mux setting and add pullup resistors. There is some
> debate about whether the pullups should be to 1.8 or 3V
This won't work for people with boards today--they would have to
modify themselves.
>
>
> Steve
>
> >
Gerald
-----Original Message-----
From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com]
On Behalf Of sakoman
Sent: Wednesday, June 25, 2008 11:59 PM
To: Beagle Board
Subject: [beagleboard] Re: I2C timeouts
Gerald
-----Original Message-----
From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com]
On Behalf Of sakoman
Sent: Wednesday, June 25, 2008 11:59 PM
To: Beagle Board
Subject: [beagleboard] Re: I2C timeouts
I will try to do a kernel patch for this and update issue #17 accordingly.
Thanks to Steve for debugging!
Dirk
In conclusion, I2C.
Sent a patch to OMAP list for this:
http://marc.info/?l=linux-omap&m=121515287023862&w=2
Please have a look if you like it and comment there.
Thanks
Dirk