IMX8-QXP-C0: I2C without M4

PBR · ‎01-21-2022

Hello,

I have a Roadlink Daughter card with a IMX8-QXP-C0 and I am using Yocto for building software.

There are 2 I2C drivers: "fsl,i2c-rpbus" and "fsl,imx7ulp-lpi2c".
If I understand, "fsl,i2c-rpbus" is using M4 and "fsl,imx7ulp-lpi2c" is not.
As I don't use M4 (when the linux is booting, M4 is not running), I would like to use "fsl,imx7ulp-lpi2c" but it does not work.

So my questions:

Is it possible to use i2C without M4?
If yes, is it with the "fsl,imx7ulp-lpi2c" driver and is there a special way to make it work?

Thank you for your help.

PBR · ‎01-28-2022

Hello BiyongSUN,

I found my error: the Uboot DTS was not compatible with the linux DTS. There were a bad I2C1 access on uboot which prevents linux to use I2C1 properly.

Thank you for your help BiyongSUN.

Is it possible for you to see my ticket on M4 (https://community.nxp.com/t5/i-MX-Processors/IMX8QXP-M40-boot-issue/m-p/1397635) as at the end, I will need M4?

在原帖中查看解决方案

BiyongSUN · ‎01-23-2022

It is BSP settings for i.MX8QXP C0 MEK board hardware design.

Because under this hardware design with m4 hardware partition, the i2c will give to m4 partition.

To use the m4 side i2c, m4 program has to provide i2c agent. Because A35 side could not directly use the i2c on M4 side.

I need to say again, because of the hardware design of i.MX8QXP C0 MEK.

If you have binary demo image

imx-boot-imx8qxpc0mek-sd.bin-flash no m4 partition. This image uses physical i2c.

imx-boot-imx8qxpc0mek-sd.bin-flash_linux_m4 has m4 partition. This image uses i2c agent.

flash and linux_m4 let you know the parameters from imx-mkimage

You can read the follow document:

Understand iMX8QX Hardware Partitioning By Making M4 Hello world Running Correctly
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Understand-iMX8QX-Hardware-Partitioning-...

PBR · ‎01-24-2022

Hello BiyongSUN,

Thank you for your answer.
So here is what I understand, please tell me if I am wrong or right:
1- By software, you can enable or disable the M4 hardware partition on the MEK board
2- It is the SCFW firmware which activates or not the M4 partition inside the "if (alt_config != SC_FALSE)" block in board_system_config()
3- When you compile for QSPI, you use flash_spl_flexspi/flash_flexspi, so you don't use M4
4- So in this case (QSPI boot), the M4 hardware partition is disabled
5- So in this case (QSPI boot), A35 has a direct access to I2C
6- Direct access is done by the LPI2C driver

But unfortunately it does not work. So if I am wrong on these 6 asserts, please tell me which ones are false.

When I tried to access, the byte is sent and there is an ACK (I saw it with my bus analyser) but the IMX detects an ALF (Arbitration Lost Flag).
So lpi2c_imx_bus_busy() in i2c-imx-lpi2c.c file returns -EAGAIN.
Do you have any idea where it could come from?

BiyongSUN · ‎01-25-2022

Because you are using the Roadlink Daughter card, not NXP i.MX8QXP MEK board.

We can not help more.

If you can access the i2c register, that proves the i2c is assigned on A35 side.

From your input "6- Direct access is done by the LPI2C driver", it seems done.

And if you are using u-boot, u-boot has i2c command to do test.

Also under linux, it has like i2c-detect application.

What you need to do is to make the dts file correct. then the Linux will take care of the rest of the work.

For the board Roadlink Daughter card, you need to get more help for the board vendor.

PBR · ‎01-25-2022

Hello BiyongSUN,

Roadling Dauther and i.MX8QXP MEK board are using the same board : "MCIMX8QXP-CPU" so I think (and hope) you could help me.

When I boot from SD card (flash_linux_m4), I2C is working with "fsl,i2c-rpbus" driver.
But I need to boot with QSPI.
As I don't succeed to use the lpi2c driver, maybe I could make it work with rpbus driver.

So here are some questions:
Why is M4 binary not included when you build for QSPI (flash_spl_flexspi) in the file soc.mak?
When I modify soc.mak to include M4 binary, M4 works when I have uboot but when the Linux image (from SD card) starts, the M4 stops running.

So I have this case:
- Boot from SD card, I have Uboot, M4 is running. I launch Linux from SD card, M4 is still running.
- Boot from QSPI, I have Uboot, M4 is running. I launch Linux from SD card, M4 stops!!

So what is the difference?

The only difference I saw is in this logs:

When M4 is running:
[] Zone ranges:
[] DMA32 [mem 0x0000000080200000-0x00000000fdffffff]
[] Normal empty
[] Movable zone start for each node
[] Early memory node ranges
[] node 0: [mem 0x0000000080200000-0x0000000083ffffff]
[] node 0: [mem 0x0000000086200000-0x0000000087ffffff]
[] node 0: [mem 0x0000000094c00000-0x00000000fdffffff]

When M4 stops:
[] Zone ranges:
[] DMA32 [mem 0x0000000080200000-0x00000000fdffffff]
[] Normal empty
[] Movable zone start for each node
[] Early memory node ranges
[] node 0: [mem 0x0000000080200000-0x0000000083ffffff]
[] node 0: [mem 0x0000000086200000-0x0000000087ffffff]
[] node 0: [mem 0x0000000090020000-0x00000000901fffff]
[] node 0: [mem 0x0000000090500000-0x0000000091ffffff]
[] node 0: [mem 0x0000000094c00000-0x00000000fdffffff]

Is there any memory problem?

Thank you for your help.

BiyongSUN · ‎01-25-2022

If you think Roadling Dauther and i.MX8QXP MEK board are using the same board : "MCIMX8QXP-CPU",

Here is the test on i.MX8QXP MEK. But I do think they are different board using the same chip.

Assume you are right, that is to say, we can prove on i.MX8QXP MEK.

1. boot from qspi w/o M4(w/o hardware partition)

U-Boot 2021.04-lf_v2021.04+g1c0116f3da (Sep 06 2021 - 08:48:23 +0000)

CPU: NXP i.MX8QXP RevC A35 at 1200 MHz at 27C

Model: NXP i.MX8QXP MEK
Board: iMX8QXP MEK
Boot: FLEXSPI
DRAM: 3 GiB
TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C1 0x50]

root@imx8qxpc0mek:~# for i in /sys/class/i2c-adapter/* ; do echo $i ;cat $i/name; cat $i/device/of_node/compatible; echo; echo; done
/sys/class/i2c-adapter/i2c-1
5a810000.i2c
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-16
37230000.i2c
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-17
i2c-1-mux (chan_id 0)
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-18
i2c-1-mux (chan_id 1)
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-19
i2c-1-mux (chan_id 2)
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-20
i2c-1-mux (chan_id 3)
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-21
58226000.i2c
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-22
56226000.i2c
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-23
56246000.i2c
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

root@imx8qxpc0mek:~# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- UU -- -- UU UU --
20: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- UU -- -- -- -- -- -

2. boot from sd1 w/ m4(w/ hardware partition)

U-Boot 2021.04-lf_v2021.04+g1c0116f3da (Sep 06 2021 - 08:48:23 +0000)

CPU: NXP i.MX8QXP RevC A35 at 1200 MHz at 28C

Model: NXP i.MX8QXP MEK
Board: iMX8QXP MEK
Boot: SD1
DRAM: 2.8 GiB
VService: Connection is ok on MU mu@5d230000
TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C1 0x50]
MMC: FSL_SDHC: 0

root@imx8qxpc0mek:~# for i in /sys/class/i2c-adapter/* ; do echo $i ;cat $i/name; cat $i/device/of_node/compatible; echo; echo; done
/sys/class/i2c-adapter/i2c-1
i2c-rpmsg-adapter
fsl,i2c-rpbus

/sys/class/i2c-adapter/i2c-12
i2c-rpmsg-adapter
fsl,i2c-rpbus

/sys/class/i2c-adapter/i2c-14
i2c-rpmsg-adapter
fsl,i2c-rpbus

/sys/class/i2c-adapter/i2c-15
i2c-rpmsg-adapter
fsl,i2c-rpbus

/sys/class/i2c-adapter/i2c-16
58226000.i2c
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-17
56226000.i2c
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-18
56246000.i2c
fsl,imx8qxp-lpi2cfsl,imx7ulp-lpi2c

/sys/class/i2c-adapter/i2c-5
i2c-rpmsg-adapter
fsl,i2c-rpbus

root@imx8qxpc0mek:~# i2cdetect [ 33.856217] usb_otg1_vbus: disabling
-y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- UU -- -- UU -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- 71 -- -- -- -- -- --
root@imx8qxpc0mek:~# i2cdetect -y 16
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

PBR · ‎01-26-2022

Hello BiyongSUN,

If you see the attached files, you will see it is the same board.

And I think you reproduce my issue!

Please see your results:
With Flexspi boot, i2cdetect cannot access to the i2c devices ('UU' is displayed meaning devices are busy)
You can also do this command 'i2cget 1 80' to try to access 0x50 device and you will have the result: 'Error: Could not set address to 0x50: Device or resource busy'

With SD boot, i2cdetect can access to the 0x50 & 0x71 i2c devices
You can also do this command 'i2cget 15 80' to access 0x50 device and you will have a value, no error.

Doesn't it prove i2c devices cannot be accessed with flexspi boot while it is possible with SD boot?

BiyongSUN · ‎01-26-2022

it should be busy, because 0x50 is used by typec chip.

w/ m4, the bsp doesn't use the typec device and 0x71 pca i2c exp, either.

That is why you can access it.

But it should be a problem for typeC function. w/ or w/o m4 agent, they all should be busy there.

Not busy, it means typeC chip is not used by Linux.

I will double check it.

usion

as well

PBR · ‎01-26-2022

Hello BiyongSUN,

Yes I know an I2C device can be busy.
But with FlexSPI boot, it is always busy, not with SD boot.
Let's take an easier device : the 2 IO expander bus (PCA9557).
With FlexSPI boot, there are always busy, not with SD boot. (see below).
With i2cdetect command: with FlexSPI boot, it is always 'UU', with SD boot, you can have some values, meaning these devices are available.

So it seems there is a problem with I2C+FlexSPI boot
If I am wrong, tell me which I2C device you can access with i2cget on your board when FlexSPI booting.

** Test on I/O expander **

>> FLEXSPI boot:
root@imx8qxpc0mekroadlink:~# ./i2cdetect -y 17
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- UU -- -- UU UU --
20: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- UU -- -- -- -- -- --
./i2cget 17 26
./i2cget 17 29

root@imx8qxpc0mekroadlink:~# ./i2cget 17 26
Error: Could not set address to 0x1a: Device or resource busy
root@imx8qxpc0mekroadlink:~# ./i2cget 17 29
Error: Could not set address to 0x1d: Device or resource busy

>> SD boot:
/sys/class/i2c-adapter/i2c-1
i2c-rpmsg-adapter
fsl,i2c-rpbus

root@imx8qxpc0mekroadlink:~# ./i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- 1a -- -- 1d -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- 71 -- -- -- -- -- --
root@imx8qxpc0mekroadlink:~# ./i2cget 1 26
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-1, chip address 0x1a, current data
address, using read byte.
Continue? [Y/n]
0xff

BiyongSUN · ‎01-26-2022

The m4 i2c agent the behavior the same as physical i2c.

and you log also shows the same. 0x50 is UU.

If it is not UU at 0x50, the type C on board doesn't work.

SW: Binary demo image LF_v5.10.52-2.1.0_images_IMX8QXPC0MEK

HW：i.MX8QXP C0 MEK.