Wandboard - I2C error when booting with HDMI cable

Hi Anatolij and Heiko,
When booting a wandboard with a HDMI cable connected I get the following I2C messages:
U-Boot 2020.01-rc4-00151-g8dc20b6ae3-dirty (Dec 09 2019 - 21:07:48 -0300)
CPU: Freescale i.MX6QP rev1.0 at 792 MHz Reset cause: WDOG DRAM: 2 GiB force_idle_bus: sda=0 scl=1 sda.gp=0x6d scl.gp=0x6c force_idle_bus: failed to clear bus, sda=0 scl=1 force_idle_bus: sda=0 scl=1 sda.gp=0x6d scl.gp=0x6c force_idle_bus: failed to clear bus, sda=0 scl=1 PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... OK auto-detected panel HDMI Display: HDMI (1024x768)
The Wandboard logo is properly displayed via HDMI, but I am wondering what can we do to get rid of these I2C messages?
If the board is booted without the HDMI cable connected such messages do not appear.
Any ideas?
Thanks,
Fabio Estevam

Hello Fabio,
Hope you are fine?
Am 10.12.2019 um 01:33 schrieb Fabio Estevam:
Hi Anatolij and Heiko,
When booting a wandboard with a HDMI cable connected I get the following I2C messages:
U-Boot 2020.01-rc4-00151-g8dc20b6ae3-dirty (Dec 09 2019 - 21:07:48 -0300)
CPU: Freescale i.MX6QP rev1.0 at 792 MHz Reset cause: WDOG DRAM: 2 GiB force_idle_bus: sda=0 scl=1 sda.gp=0x6d scl.gp=0x6c force_idle_bus: failed to clear bus, sda=0 scl=1 force_idle_bus: sda=0 scl=1 sda.gp=0x6d scl.gp=0x6c force_idle_bus: failed to clear bus, sda=0 scl=1
Hmm... seems to come from "arch/arm/mach-imx/i2c-mxv7.c" ...
PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... OK auto-detected panel HDMI Display: HDMI (1024x768)
The Wandboard logo is properly displayed via HDMI, but I am wondering what can we do to get rid of these I2C messages?
If the board is booted without the HDMI cable connected such messages do not appear.
Any ideas?
Hmm.. I have only a DL based wandboard ... but I try to find time to boot it with a hdmi cable attached ... ok, bootline:
force_idle_bus: sda=0 scl=1 sda.gp=0x6d scl.gp=0x6c
-> sda pin is 0x6d = 109 = gpio4_13
in arch/arm/dts/imx6dl-pinfunc.h: #define MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x264 0x64c 0x874 0x4 0x1 #define MX6QDL_PAD_KEY_ROW3__GPIO4_IO13 0x264 0x64c 0x000 0x5 0x0
Ok, so i2c bus 2. from imx6qdl-wandboard.dtsi:
85 &i2c2 { 86 clock-frequency = <100000>; 87 pinctrl-names = "default"; 88 pinctrl-0 = <&pinctrl_i2c2>; 89 status = "okay"; 90 91 codec: sgtl5000@a {
ok, there is this sgtl5000 chip ... audio codec ... I do not see how this has something to do with hdmi cable ... a very fast look into wiring diagrams, shows only, that i2c2 _sda/scl goes also to camera1 (FP124-334M4) connector (wb-edm-imx6-rev-c1.pdf C1 schematics). Should have nothing to do with hdmi ...
May it is worth to check error codes in arch/arm/mach-imx/i2c-mxv7.c ?
22 gpio_direction_input(p->sda.gp); 23 gpio_direction_input(p->scl.gp); 24 25 imx_iomux_v3_setup_pad(p->sda.gpio_mode); 26 imx_iomux_v3_setup_pad(p->scl.gpio_mode); 27 28 sda = gpio_get_value(p->sda.gp); 29 scl = gpio_get_value(p->scl.gp);
especially the imx_iomux_v3_setup_pad calls are interesting ... is gpio_mode set correctly ?
May the pinmux is not setup to gpio mode, and so deblocking does not work and or wrong vaules
Oh, I see in board code:
450 int board_init(void) 451 { 452 /* address of boot parameters */ 453 gd->bd->bi_boot_params = PHYS_SDRAM + 0x100; 454 455 #if defined(CONFIG_VIDEO_IPUV3) 456 setup_i2c(1, I2C1_SPEED_NON_DM, 0x7f, &mx6dl_i2c2_pad_info); 457 if (is_mx6dq() || is_mx6dqp()) { 458 setup_i2c(1, I2C1_SPEED_NON_DM, 0x7f, &mx6q_i2c2_pad_info); 459 setup_i2c(2, I2C2_SPEED_NON_DM, 0x7f, &mx6q_i2c3_pad_info); 460 } else { 461 setup_i2c(1, I2C1_SPEED_NON_DM, 0x7f, &mx6dl_i2c2_pad_info); 462 setup_i2c(2, I2C2_SPEED_NON_DM, 0x7f, &mx6dl_i2c3_pad_info); 463 } 464 465 setup_display(); 466 #endif 467 468 return 0; 469 }
So forget my speculation above ... :-(
The only possibility is, that the hdmi cable blocks i2c bus 2 ...
Or timeout until it gets unblocked is too low!
May you increase timeout in "arch/arm/mach-imx/i2c-mxv7.c"
49 elapsed = get_timer(start_time); 50 if (elapsed > (CONFIG_SYS_HZ / 5)) { /* .2 seconds */ 51 ret = -EBUSY;
?
Currently no more ideas ... sorry.
bye, Heiko

Hi Heiko,
On Tue, Dec 10, 2019 at 2:26 AM Heiko Schocher hs@denx.de wrote:
May you increase timeout in "arch/arm/mach-imx/i2c-mxv7.c"
49 elapsed = get_timer(start_time); 50 if (elapsed > (CONFIG_SYS_HZ / 5)) { /* .2 seconds */ 51 ret = -EBUSY;
Thanks for your email.
Unfortunately increasing the timeout does not help.
I will investigate more.
Thanks
participants (2)
-
Fabio Estevam
-
Heiko Schocher