How to enable and use I2C2 (Raspberry Pi–style header) on Genio-510 EVK?

Yocto
1

Hi,
I am working on the Genio-510 EVK and trying to bring up an NFC module (NXP PN7160) using the I2C2 interface available on the Raspberry-Pi compatible header.

My goal is to connect PN7160 over I2C2 and verify the device address using:
i2cdetect -y 2
But I2C2 is currently empty / blank, and no devices appear on the bus.

What I have tried so far

1. Checked the I2C controller nodes

I verified the device-tree path:
/sys/firmware/devicetree/base/soc/i2c@11281000

I confirmed the I2C controller exists but is not communicating on I2C2 pins.

2. Tried probing the bus

Running:
i2cdetect -y 2

Shows a completely blank table (no ACK).

3. Verified GPIO pin numbers

Using:
gpioinfo | grep -E “68|69”

I didn’t see expected SDA2/SCL2 functions mapped.

4. Checked kernel logs

dmesg | grep -i i2c

No entry for I2C2 initialization or failure.

5. Looked for overlays

I checked the Genio image for overlay support:

  • fw_printenv fdt_overlays shows empty

  • dumpimage -l fitImage does not list any overlay for I2C2

  • There is no device-tree-overlays.bb in the BSP

It appears I2C2 may be disabled or not pinned by default.

What I need help with

How do I enable or configure the I2C2 pins on Genio-510 EVK?

Specifically:

  1. Which device-tree node corresponds to I2C2 on the Raspberry-Pi header?
    Example: i2c@1128xxxx or something else?

  2. What pinctrl settings are required to map SDA2/SCL2 to the RPi header pins?

  3. Is there a device-tree overlay already available to enable I2C2?
    Or do I need to modify the base DTB?

  4. Is there any default conflict (e.g., pins used by GPIO, audio, or cameras) that blocks I2C2?

  5. What is the correct way to test I2C2 is active on Genio-510?

Goal

Once I2C2 is active, I will connect the PN7160 NFC module and complete the bring-up.

If needed I can share my DTS overlay file or logs.

Thanks in advance!

3

Hi @Niranjan_M ,

If you use IoT Yocto software and Genio-510 EVK, the I2C2 bus should be available by default.

  1. Refer to the online document Genio 510/700-EVK — IoT Yocto documentation
    The I2C2_SDA and I2C2_SCL are the pin 3 and pin 5 of the Raspberry Pi HAT.
    It corresponds to i2c@11281000 in the mt8370.dtsi

  2. The pinctrl setting used for I2C2 is in mt8370-genio-510-evk.dts.
    I2C2_SDA is GPIO60 and I2C2_SCL is GPIO59.

    	i2c2_pins: i2c2-pins {
		pins {
			pinmux = <PINMUX_GPIO60__FUNC_B1_SDA2>,
				 <PINMUX_GPIO59__FUNC_B1_SCL2>;
			bias-pull-up = <MTK_PULL_SET_RSEL_011>;
			drive-strength-microamp = <1000>;
		};
	};

  3. The I2C bus is already enabled in the in-tree DTS. What you need to do is add a DTB overlay for your I2C device. You can refer to other DTBO, like the camera device, to implement one.

  4. No conflict blocks I2C2. However, you need to short the jumper J4201 to enable RPi HAT power.

  5. If you have a logic analyzer, you can connect it to the I2C2 pins. When running the command i2cdetect -y 2, the I2C bus should have the signal.

4

Hi,

Thanks for the clarification.

I have a few follow-up points to confirm so I can proceed correctly with the PN7160 bring-up:
i2cdetect -y 2

shows an empty table (no ACK).
Also, on an oscilloscope I do not see any SCL/SDA toggling during the scan.

Is this expected if no device is connected?
Or should i2cdetect still generate START/STOP pulses on SCL/SDA even with no device present?

2. GPIO controller phandle for PN7160

For adding the PN7160 overlay, can you please confirm the correct gpio controller in device-tree?

Is the correct reference:
&gpio0

for GPIO60 / GPIO59 / GPIO68 / GPIO69?

(Just want to avoid mapping mismatches.)
3. Jumper J4201

I have enabled J4201 for RPi header power.
Is any additional jumper required for I2C2 or 3.3V supply to the PN7160 VIN?

4.Example DT overlay

You mentioned creating an overlay similar to camera overlays.

Do you have a minimal reference overlay example for adding a simple I2C device to I2C2, just to confirm the correct structure (target-path + pinctrl usage)?

5. I2C2 pinmux reconfiguration

Since the base DTS configures the pinmux:

PINMUX_GPIO60__FUNC_B1_SDA2
PINMUX_GPIO59__FUNC_B1_SCL2

Should a DT overlay avoid re-defining the pinmux completely?

(i.e., only add the child node under i2c@11281000)

6. PN7160 stack validation

I am using the NXP NFC demo app (nfcDemoApp poll), but it crashes due to empty I2C reads (likely because IRQ/VEN never trigger).
Can you confirm if additional kernel drivers or config options are required on Genio for the PN7160 to function?

Thanks again for the support — once I2C2 activity is confirmed, I will proceed with validating the PN7160 overlay

5

Hi @Niranjan_M ,

When running i2cdetect -y 2, the I2C master will poll all addresses, so you can expect to observe the signal even if there’s no external device connected.
The idle state of the I2C bus is HIGH, so you can directly measure the I2C bus pins to see whether it stays HIGH when there’s no operation.

I2C2_SDA and I2C2_SCL are GPIO60 and GPIO59. Why do you need GPIO68 and GPIO69?
If your device requires more GPIO pins to control power, clock, etc., you indeed need to configure other GPIO pins.

No, but you can refer to other I2C devices like it5205fn, which is simpler.

No, it’s the I2C bus that is already configured in mt8370-genio-510-evk.dts.

It depends on how to use PN7160. You may need to ask the vendor of this PN7160. We won’t have all device vendor drivers in the IoT Yocto kernel.

6

Hi,

Thanks for the detailed explanation.

I tested the I2C2 pins (GPIO59=SCL, GPIO60=SDA) with a logic analyzer while running:
i2cdetect -y 2

But I still do not see any SCL/SDA toggling — both remain HIGH and idle.
This happens even when no device is connected, which according to your explanation means the I2C master is not driving the bus.

To help isolate the issue, could you please confirm the following:

1. Should I expect I2C2 to operate without enabling any additional regulator or power rail?

I already enabled J4201 (RPi HAT 3.3V).
Is any additional jumper or PMIC rail required for I2C2?

2. Is there any pin conflict on GPIO59/60:

  • Are these pins shared with any audio, camera, debug, or PMIC function?

  • Is there a way to dump pinctrl configuration at runtime to verify the active function of each pin?

3. Is the correct runtime path for the I2C2 controller:
/sys/firmware/devicetree/base/soc/i2c@11281000

And should this node appear in dmesg during boot?

4. For VEN/IRQ (GPIO68/69), is gpio0 the correct controller for overlay usage?

Example: irq-gpios = <&gpio0 68 GPIO_ACTIVE_LOW>;

Once I can get the I2C2 bus toggling properly, I will proceed to integrate the PN7160 driver from NXP.

Thanks again for your support.

7

Hi @Niranjan_M ,

Yes. If you use the Genio 510 EVK with the official IoT Yocto release image, the I2C2 bus should be enabled by default without any additional regulator, power, pinctrl, or dtbo settings. Only the jumper J4201 should be set.

No, they are only for I2C2 on the Genio 510 EVK.

Yes, I2C2 is i2c@11281000.

Could you please share the software version and the boot configuration you are using?
Let’s align the environment.

cat /etc/buildinfo # IoT Yocto v25.0~ (Scarthgap)
cat /etc/build     # IoT Yocto ~v24.1 (Kirkstone)
cat /etc/os-release
fw_printenv | grep boot_conf
8

Hi,

Thank you for the clarification.

Here are my environment details:

root@genio-510-evk:~# cat /etc/buildinfo
DISTRO = rity-demo
DISTRO_VERSION = 25.0-release
…
meta-mediatek-bsp = HEAD:b7b65915a95b743d4e37de28d10ece04135fa6af – modified
…
meta-myconfigs = : – modified
…

root@genio-510-evk:~# cat /etc/os-release
ID=rity-demo
NAME=“Rity Demo Layer”
VERSION=“25.0-release (scarthgap)”
PRETTY_NAME=“Rity Demo Layer 25.0-release (scarthgap)”

root@genio-510-evk:~# fw_printenv | grep boot_conf
boot_conf=#conf-mediatek_mt8370-genio-510-evk.dtb#conf-apusys.dtbo#conf-video.dtbo#conf-display-hdmi.dtbo#conf-display-dsi.dtbo#conf-camera-imx214-csi0.dtbo
To confirm the root cause, could you please help with these key questions:

1. On an official Genio-510 EVK with IoT Yocto 25.0, does I2C2 generate clock pulses during i2cdetect -y 2?

Even with no device connected?

(This will confirm whether my board/software behaves differently.)

2. Could any of the modified layers (e.g. meta-mediatek-bsp, meta-myconfigs) disable or override I2C2 pinctrl?

If yes, which files should I verify?

3. What is the correct runtime method to verify that GPIO59/60 are really using the I2C2 pinmux?

Example expected debug path:
/sys/kernel/debug/pinctrl//pinmux-pins

Please confirm the correct pinctrl path for MT8370 on Genio-510.

4. If possible, could you share from a reference EVK:

  • Output of: i2cdetect -y 2

  • pinmux info for GPIO59/60 (SCL2,SDA2)

This will help me compare my configuration with a known-working reference.

Once I2C2 toggling is confirmed, I will add the PN7160 overlay and proceed with the driver integration.

Thank you for your support.

Best regards,
Niranjan

9

Hi @Niranjan_M

Yes, the I2C master will generate the signal to scan the external devices even if there’s no device connected.

It’s possible if your modified layer changes the DTS or driver setting.
So, to eliminate this possibility, you could try the IoT Yocto official prebuilt image.
Download the prebuilt image here Download — IoT Yocto documentation

The pinctrl debug node should show that GPIO59 and GPIO60 are occupied by the I2C2 bus 11281000.i2c and are set to func1.

root@genio-510-evk:~# cat /sys/kernel/debug/pinctrl/10005000.pinctrl-pinctrl_paris/pinmux-pins
...
pin 59 (GPIO59): 11281000.i2c (GPIO UNCLAIMED) function func1 group GPIO59
pin 60 (GPIO60): 11281000.i2c (GPIO UNCLAIMED) function func1 group GPIO60

There’s no device connected to my Genio 510 EVK, so the output of i2cdetect is empty.

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