Originally owned by the firmware, but largely now used from the kernel as we've switched away from the legacy camera and display stacks.Hey,
I have spent the last hours trying to understanding the I2C concept on the CM4. In the follwing I will summarize my findings and my remaining questions, grouped by I2C bus. I would be happy if somebody could help answer the questions and correct me, if some findings are wrong.
I2C0
Owned by the VPU/Firmware by default
- Does this cause problems? Can the bus be used normally (if i2c_vc=on is NOT set in config.txt)?
It can be, but 28&29 are used for ethernet on a CM4, so you'd be advised not to try that muxingCan be muxed between GPIO0/1, GPIO28/29 and GPIO44/45
It's a quirk of the kernel mux framework. The parent controller is also created, but with no pinctrl associated to it. If you try using it, you'll see whichever of i2c-0 and i2c-10 was used last (there is an option to deselect any output, but that isn't configured).- Muxing is activated by setting i2c_vc=on in config.txt or by enabling i2c0if and i2c0mux in a DTOverlay
- When muxed /dev/i2c-0 corresponds to GPIO0/1, /dev/i2c-10 (= i2c_csi_dsi) corresponds to GPIO28/29 or GPIO44/45 (depending on the board wiring)
- When muxed /dev/i2c-11 also appears. What is the reason behind this interface?
You've already described it. It enables the i2c0if and i2c0mux.dtOverlay=i2c0,<param> disables the muxing of the bus and assigns it to fixed pins (GPIO0/1, GPIO28/29, GPIO44/45 or GPIO 46/47) -> Becomes /dev/i2c-0
What exactly does i2c_vc=on do?
dtoverlay=i2c0 enables i2c0if and assigns it some GPIOs.
It would be, so don't do it. The kernel should throw an error if you try and claim already claimed GPIOs.I2C1
Owned by the ARM by default
dtOverlay=i2c1,<param> can be used to assign the bus to GPIO2/3 or GPIO44/45 -> Becomes /dev/i2c-1
- What happens when GPIO44/45 is selected for I2C1 and muxing is activated for I2C0? Isn't this a conflict?
dtparam=i2c_arm=on enables i2c1.What exactly does i2c_arm=on do?
dtoverlay=i2c1 enables i2c1 and allows you to change the GPIO assignments.
It would be, so don't do it.I2C3
Only available in BCM2711
dtOverlay=i2c3,<param> can be used activate I2C3 and to connect it to either GPIO2/3 or GPIO4/5 -> Becomes /dev/i2c-3
I2C4
Only available in BCM2711
dtOverlay=i2c4,<param> can be used activate I2C4 and to connect it to either GPIO6/7 or GPIO8/9 -> Becomes /dev/i2c-4
I2C5
Only available in BCM2711
dtOverlay=i2c5,<param> can be used activate I2C5 and to connect it to either GPIO10/11 or GPIO12/13 -> Becomes /dev/i2c-5
I2C6
Only available in BCM2711
dtOverlay=i2c6,<param> can be used activate I2C6 and to connect it to either GPIO0/1 or GPIO22/23 -> Becomes /dev/i2c-6
- What happens when GPIO0/1 is selected for I2C6 and muxing is activated for I2C0? Isn't this a conflict?
Statistics: Posted by 6by9 — Wed Nov 20, 2024 6:21 pm