i.MX 8M Plus: M7 write to I2C3 I2CR register causes M7 and A53 to hang

[aheck]

Hello,

I am trying to use I2C3 on the M7 core of an i.MX 8M Plus while leaving I2C1 and I2C2 for the A53 to use. I am using a custom board which was derived from the i.MX 8M Plus evaluation kit.

With the A53 stopped in U-Boot, I can use a Segger J-Trace to program and debug the M7, and I see the M7 using I2C3 to successfully communicate with on board peripherals. However, when I launch the same firmware build using remoteproc, both the A53 and M7 lock up when the M7 writes to the I2C3 I2CR register.

I understand that sharing peripherals between the A53 and M7 has issues and is not recommended, so I've taken several steps to try and prevent the A53 from using I2C3. Here is an overview on my present Yocto configuration:

• Until I create my own machine configuration for yocto, I am editing the imx8mp-evk machine configuration in place.
• I have modified the imx8mp-evk machine to skip all device trees other than the imx8mp-evk.dts.
• I have explicitly disabled the I2C3,4,5,6 device tree nodes in imx8mp-evk.dts.
• I have modified imx8mp-evk.dts to support rpmsg, remoteproc, and I've added the rmtcore_shm module used in the low-power audio example; all of these modules are working correctly.
• To support rmtcore_shm, I modified the linux,cma memory segment to only be placed in RAM that the M7 can access; previously on some builds it would be placed higher than 0xBFFFFFFF, the highest RAM address the M7 can access.

I've attached my modified .dts and .dtsi; is there a step I am missing to prevent the A53 and Linux from accessing the I2C3 peripheral?

What would cause the M7 and A53 to hang when the M7 accesses I2C3?

[aheck · Accepted solution]

I believe I have found the issue.  In short, make sure to initialize a peripheral's clock before accessing any of the peripheral's registers.

In my M7 firmware, when initialing the I2C peripherals, I was using a ResetBus() function I wrote which calls I2C_MasterTransferAbort() before calling I2C_MasterInit().

When the M7 ran from u-boot, this worked, as I am assuming the I2C peripheral clocks were already running.  However, when the M7 was launched by remoteproc, the I2C peripheral clocks were not running, and therefore when I2C_MasterTransferAbort() tried to access peripheral registers, it got stuck.

Thanks for the help troubleshooting!

[JosephAtNXP]

Hi,

Thank you for your interest in NXP Semiconductor products,

They are all disabled in dtsi, could you try to remove the i2c unused node with their pin_ctrl nodes so there is no register of the pins used in both u-boot and linux dts?

Let me know how this goes.

Regards

[aheck]

I commented out pinctrl_i2c3 and pinctrl_i2c5 in the .dts file, and I had the same lock-up.  I've attached the updated .dts to this reply.

I modified the M7 firmware to skip initialing I2C3 and began initializing I2C4, and I had the same lock up, where it worked fine when launched from U-Boot, but locked up when launched from remoteproc.

[JosephAtNXP]

Hi,

The issue is probably this, could you check it out?

Regards

[aheck]

I have been executing 'run prepare_mcore' in u-boot before booting.

As a sanity check for this thread, I verified that I could boot the built-in imx8mp_m7_TCM_sai_low_power_audio.elf image.  I believe this image accesses the I2C busses.  The demo ran without crashing, so I stopped the M7 using remoteproc.  I then launched my .elf, and the i.MX stopped when the M7 accessed an I2C peripheral.