i.MX6 Quad edid and/or i2c-1 broken?

[Alexander Holler]

Hello,

I'm wondering what's the problem with EDID on the wandboard quad c1.

If I turn on debug for i2c, it looks like i2c-1 (or 0 if you start
counting at 0) is broken.

I'm not sure if I have read the schematics correctly, but it looks like
a AT24C08 eeprom, DDC from the monitor and the SGTL5000 are connected to
i2c-1.

So one should at least be able to read the eeprom. But I was unable to
do that during my limited tests (besides that reading ddc never worked).

I see several possible problems:

- The hardware is broken. Either the in-chip i2c or the analog stuff on
the board.

- The SGTL5000 doesn't initialize correctly and therefor kills the
i2c-bus. There is an errata for that chip which talks about a hw-problem.

- The SGTL5000 needs some sw-initialization to not kill the i2c-bus.

Has anyone a hint what actually might be the problem? I really don't
want to fiddle with the hw on my new board I've just received a few days
before. E.g. did someone test what happens if the SGTL5000 is
disconnected (hard) from the i2c-bus?

This seems to be a very old problem, which makes me wonder, because
handling and testing i2c is usually relatively easy. So it would make me
wonder if no one else already found the problem.

Regards,

Alexander Holler

[Alexander Holler]

Just in case someone wants to play with I2C in U-Boot, here are the
necessary changes for U-Boot mainline to enable i2c commands (pasted =>
likely with format-errors):

diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index f1951dc..847d0ca 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -27,6 +27,8 @@
#include <linux/fb.h>
#include <phy.h>
#include <input.h>
+#include <asm/imx-common/mxc_i2c.h>
+#include <i2c.h>

DECLARE_GLOBAL_DATA_PTR;

@@ -45,6 +47,54 @@ DECLARE_GLOBAL_DATA_PTR;
#define USDHC3_CD_GPIO IMX_GPIO_NR(3, 9)
#define ETH_PHY_RESET IMX_GPIO_NR(3, 29)

+#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+
+struct i2c_pads_info i2c_pad_info0 = {
+ .scl = {
+ .i2c_mode = MX6_PAD_EIM_D21__I2C1_SCL | PC,
+ .gpio_mode = MX6_PAD_EIM_D21__GPIO3_IO21 | PC,
+ .gp = IMX_GPIO_NR(3, 21)
+ },
+ .sda = {
+ .i2c_mode = MX6_PAD_EIM_D28__I2C1_SDA | PC,
+ .gpio_mode = MX6_PAD_EIM_D28__GPIO3_IO28 | PC,
+ .gp = IMX_GPIO_NR(3, 28)
+ }
+};
+
+struct i2c_pads_info i2c_pad_info1 = {
+ .scl = {
+ .i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL | PC,
+ .gpio_mode = MX6_PAD_KEY_COL3__GPIO4_IO12 | PC,
+ .gp = IMX_GPIO_NR(4, 12)
+ },
+ .sda = {
+ .i2c_mode = MX6_PAD_KEY_ROW3__I2C2_SDA | PC,
+ .gpio_mode = MX6_PAD_KEY_ROW3__GPIO4_IO13 | PC,
+ .gp = IMX_GPIO_NR(4, 13)
+ }
+};
+
+struct i2c_pads_info i2c_pad_info2 = {
+ .scl = {
+ .i2c_mode = MX6_PAD_GPIO_5__I2C3_SCL | PC,
+ .gpio_mode = MX6_PAD_GPIO_5__GPIO1_IO05 | PC,
+ .gp = IMX_GPIO_NR(1, 5)
+ },
+ .sda = {
+ .i2c_mode = MX6_PAD_GPIO_16__I2C3_SDA | PC,
+ .gpio_mode = MX6_PAD_GPIO_16__GPIO7_IO11 | PC,
+ .gp = IMX_GPIO_NR(7, 11)
+ }
+};
+
int dram_init(void)
{
gd->ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
@@ -270,6 +320,10 @@ int board_early_init_f(void)
#if defined(CONFIG_VIDEO_IPUV3)
setup_display();
#endif
return 0;
}

@@ -305,6 +359,10 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;

+ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info0);
+ setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info1);
+ setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info2);
+
return 0;
}

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 6c74c72..e25c9c5 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -69,6 +69,34 @@
#define CONFIG_CMD_EXT2
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION
+
+#define CONFIG_CMD_I2C
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_I2C_SPEED 100000

/* Ethernet Configuration */
#define CONFIG_CMD_PING
@@ -106,6 +134,9 @@
#define CONFIG_DEFAULT_FDT_FILE "imx6q-wandboard.dtb"
#endif

[ARM Fan]

Hello,

I have a WBQUAD for a year and not really solved the EDID problem (but the last half year, I was busy with other projects, now I am working again on wandboard). I even asked in the forum if the solved the problem in the next hardware revision, but did NOT get an answer.

I just checked the schematics once again: I suppose the have some troubles with the pull ups. For HDMI EDID they use a level shifter. But R289 and R291 are not populated which would be I2C pullup after level shifter. This is why EDID ready fails I think. On the other hand signal I2C1_SCL and SDA before level shifter has 2 pullups in schematic R111 and R117 first. But also some R299 and R300 direct at the EEPROM. And 1k parallel 2,2k is less than 1k which is the minimum of I2C (at least I remember so). Maybe things are different as there is 10 ohm in between. But in general I think the messed upd things with the pullups. Maybe there is an additional issue with the SGTL5000.

Disappointing is that they failed to solve this in the revision C1.

Maybe this info gives you some starting point.

[ARM Fan]

Just found R211 and R213 in schematics, once again pullups for same I2C. If I did not overlook something, this would drive the pullup clearly out of any spec.

Am Donnerstag, 17. Juli 2014 22:14:20 UTC+2 schrieb Alexander Holler:

[Alexander Holler]

Am 18.07.2014 12:45, schrieb ARM Fan:

> Disappointing is that they failed to solve this in the revision C1.

Yes, I thought it's now the second revision and the board exists quiet
some time, so it should be a relatively safe bet and at least easy to
solve problems like this one should be have been done. But unfortunatley
it's the same as with most ARM boards (and kernels).

> Maybe this info gives you some starting point.

I'm currently just using a binary edid blob embedded in the kernel and
don't intend to fiddle with taking small resistors on and off until
someone has a proven solution. I don't like to fiddle with electronics
in SMD size.

But thanks for hints, I was too lazy to study the schematics and sum up
the resistors. I'm not even sure if the SGTL is really on I2C1. ;)

Regards,

Alexander Holler

[sels...@gmail.com]

On 18/07/14 11:45, ARM Fan wrote:

> I just checked the schematics once again: I suppose the have some troubles
> with the pull ups. For HDMI EDID they use a level shifter. But R289 and
> R291 are not populated which would be I2C pullup after level shifter.
> This is why EDID ready fails I think.

I don't particularly use video on my boards, so while I've heard some stuff
3rd hand about EDID not working on WBQuad I'd never really investigated.
For some reason, this time I did.

I suggest having a look at the datasheet for that TXS0102 level shifter
they're using for DDC. It includes 10K pullups on the chip, so theoretically
there's no need for R289/R291 on the base board.

My boards are both Rev B, I'm using vanilla kernel.org 3.15, EDID works.

Out of curosity, I populated R289/R291 with 4.7K, this causes the board to
be unable to read the EDID.
One thing that this suggests is that if what you're connecting to the HDMI
has it's own pull-ups then depending on the combined value this may be the
cause of EDID failing to be detected.
There's a section on p10 of the TXS0102 datasheet that specifically
mentions that adding external pull-ups can have other effects. Since those
pull-ups could be in the attached device I think it'll be hard to predict
the outcome in any reliable way.

Also, on my board the SGTL5000 is connected to I2C2 on the schematics while
EDID is connected to I2C1.
Analogue audio through the SGTL5000 works too, so no obvious problem with
that I2C bus either.

So while I agree that overall combined pullups on any I2C bus will
ultimately be a bad idea, practically, with the h/w I have connected, it's
not an issue for me.

> Disappointing is that they failed to solve this in the revision C1.

I'm not sure there's a hardware problem to be solved here. If it does
happen to be a problem with parallel pull-ups in external devices, it's
not clear that it could be completely fixed on the wandboard anyway.
Different design decisions for wandboard may simply mean it affects
different people.

What might be interesting is for people to test with exactly the same
kernel/u-boot binaries, that might flush out a software problem, or
a conflict between a particular revs of software/hardware

[Fabio Estevam]

On Sat, Jul 19, 2014 at 7:19 AM, <sels...@gmail.com> wrote:

> My boards are both Rev B, I'm using vanilla kernel.org 3.15, EDID works.

Same here. Audio and EDID work fine on 3.16-rc5.

Alexander, please try 3.16-rc5.

[Alexander Holler]

Am 19.07.2014 12:19, schrieb sels...@gmail.com:

> Also, on my board the SGTL5000 is connected to I2C2 on the schematics while
> EDID is connected to I2C1.

Yes, I've misread the schematics. The SGTL is actually connected to the
second bus.

Maybe we should stop talking about EDID but instead about the EEPROM.
Besides the failing EDID, I was also unable to read the eeprom which
lead to me the assumption that there must be really something broken.

The kernel has drivers for that since a long time and no HDMI device is
necessary to test it. THe following should enable it:

arch/arm/boot/dts/imx6qdl-wandboard.dtsi:

&i2c1 {
(...)
at24@50 {
// The eeprom will be available for reading in
// /sys/class/i2c-dev/i2c-0/device/0-0050/eeprom
compatible = "at24,24c08";
pagesize = <16>;
reg = <0x50>;
read-only;
};
};

Hopefully I haven't misread the schematics here too (or did something
else wrong). Enabling debugging for i2c shows which errors do happen
when the kernel tries to read it.

I can' currently test it again myself to paste the error (or another
kernel), as the board compiles KDE which might need a day.

Regards,

Alexander Holler

[sels...@gmail.com]

On 20/07/14 00:51, Alexander Holler wrote:

> Maybe we should stop talking about EDID but instead about the EEPROM.
> Besides the failing EDID, I was also unable to read the eeprom which
> lead to me the assumption that there must be really something broken.

Assuming we're talking about U17 on the SoM here, it's not installed
on either of my rev B boards, so not being able to read it is no
surprise.

[Alexander Holler]

So you mean that -X in AT24C08BN-SH-T-X isn't part of the chip-id but
means U17 is NOT populated and I have to search u17 on the board in
order to be sure?

Sounds reasonable. I already wondered what it is used for, because it's
too small to be usable as boot-device (e.g. with u-boot(-spl) as
content). Maybe my wrong assumption that it exists was supported by some
post I've seen somewhere, where someone else added the entry for the
eeprom too.

Regards,

Alexander Holler