MicroZed PMOD Zynq PS MIO I2C controller registers unmapped

Hi James,

If you have the option of using the PL I2C controller instead, I would recommend doing so.

Xilinx AR61861 provides some information on why the uses the PS I2C controller is recommended to be implemented from the PL I/Os unless you have some sort of external circuitry implemented as suggested in the Xilinx Answer Record:

https://www.xilinx.com/support/answers/61861.html

When you implement I2C in the Zynq fabric, you can add glitch filtering there and those are a standard options for the AXI I2C IP core customization.

If those are not options for you, it should still be possible to get PS I2C working under Linux.  What do your devicetree entries for I2C look like?

Regards,

-Kevin

Hi Kevin,


Thanks for replying.

Unfortunately my  work is confined to the MicroZed SOM,

And the only PMOD as you know does not allow access wia the PL, only the PS.

I will apprise my client that the PL using perhaps part of the microheader to a connection on the

main custom board may be their best option. This board is still under development.

The DTS entries were generated by petalinunx given the HDF.
 

        i2c0: i2c@e0004000 {
            compatible = "cdns,i2c-r1p10";
            status = "disabled";
            clocks = <&clkc 38>;
            interrupt-parent = <&intc>;
            interrupts = <0 25 4>;
            reg = <0xe0004000 0x1000>;
            #address-cells = <1>;
            #size-cells = <0>;
        };
 

The driver "cdns,i2c-r1p10" times out on send.

When I replace it with my custom module. I am able to see that the registers don't work by inserting trace.

Thanks for you help.

James

&i2c0 {
    clock-frequency = <400000>;
    status = "okay";
};

in another dtsi file also generated by petalinux

Hi James,

Correct me if I am wrong, but I assume that you are adding one or more slave devices to MicroZed via the PS Pmod and that this is not a multi-master configuration.

If this case, the recommended approach would be to use the Cadence driver and register I2C slave devices under it within the device tree.  Once they are registered, then the slave device drivers can be used to communicate with the slaves and the cadence driver then becomes mostly transparent for you.

In your top level DTS all of the lower level dtsi files can be overridden with additional parameters.  In the top level DTS (where the status = "okay" is found) that is where you should start adding definitions for each of the slave devices.

Here is an example device tree entry from one of the reference designs for our MicroZed EMBV which also uses PS I2C controller:

&i2c0 {

     status = "okay";

     i2cswitch@70 {

           compatible = "nxp,pca9548";

           #address-cells = <1>;

           #size-cells = <0>;

           reg = <0x70>;

           i2c@0 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <0>;

                pca9354_0: gpio@20 {

                     compatible = "nxp,pca9534";

                     reg = <0x20>;

                     gpio-controller;

                     #gpio-cells = <2>;

                     /*

                     gpio_hdmii_reset_b {

                           gpio-hog;

                           gpios = <0 1>;

                           output-high;

                     };

                     */

                };

           };

           i2c@1 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <1>;

                adv7611: hdmi-rx@4c {

                     compatible = "adi,adv7611";

                     reg = <0x4c>;

                     reset-gpios = <&pca9354_0 0 1>;

                     hpd-gpios = <&pca9354_0 2 0>;

                     adi,default-input = <0>;

                     #address-cells = <1>;

                     #size-cells = <0>;

                     port@0 {

                           reg = <0>;

                     };

                     port@1 {

                           reg = <1>;

                           embv_adv7611_out: endpoint {

                                remote-endpoint = <&embv_vcap_hdmi_in>;

                           };

                     };

                };

           };

           i2c@2 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <2>;

                embv_adv7511: adv7511@39 {

                     compatible = "adi,adv7511";

                     reg = <0x39>;

                     pd-gpios = <&pca9354_0 4 0>;

                     adi,input-depth = <8>;

                     adi,input-colorspace = "yuv422";

                     adi,input-clock = "1x";

                     adi,input-style = <2>;

                     adi,input-justification = "left";

                     adi,clock-delay = <0x06>;

                     adi,embedded-sync = "true";

                };

           };

           /*

           i2c@4 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <4>;

                adau1761: adau1761@3b {

                     compatible = "adi,adau1761";

                     reg = <0x3b>;

                };

           };

           */

           /* PYTHON-1300-C camera module */

           i2c@5 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <5>;

                /* prototype hardware : PCA9554 at address 0x3C */

                /*

                pca9554_0: gpio@3c {

                      compatible = "nxp,pca9554";

                     reg = <0x3c>;

                     gpio-controller;

                     #gpio-cells = <2>;

                };

                */

                /* production hardware : PCA9554 at address 0x24 */

                pca9554_0: gpio@24 {

                     compatible = "nxp,pca9554";

                     reg = <0x24>;

                     gpio-controller;

                      #gpio-cells = <2>;

                };

           };

     };

From this MZEMBV specific mzembv-top-sdsoc.dts file, we can see that the following devices are being controlled by the above PS I2C driver:

•   PCA9548 (I2C mux)
•   PCA9534 (I2C I/O expander)
•   ADV7611 (HDMI input)
•   ADV7511 (HDMI output)
•   PCA9554 (I2C I/O expander, on PYTHON camera module)

My recommendation would be to use one of those slave device drivers as an example starting point for the I2C slave device you are prototyping up right now.  Again, this is all assuming that you are using a single master to multiple slave I2C bus architecture.

Regards,

-Kevin

Hi Kevin,

Thanks again for your help. I really appreciate it.

Actually there is only one I2C slave device attached to the PMOD. I tried the DTS approach with a slave that you describe, without effect.

In the ZedBoard I had used the PL based axi_iic core as I2C0, but just used the dev-i2c0 to access it, so I used the same approach under Petalinux and the generated DTS and DTSI sustained this configuration.

For this EEPROM fixture, I did encounter a problem where the driver missed the end of send interrupt, so I modified it to use a poll on the isr status register to complete the message process.

So I presumed that I may be encountering a similar problem here on the MicroZed SOM. But what I found was not the case. I don't see anything in your reply that would lead to thining that the DTSI is superseding the 0xe0004000 address for the bank of registers. And I don't see anything in my design. But the kernel debug trace revealed that the registers somehow were not actually mapped and writing to the register address was like to a floating memory address. The written data for R/W registers did not read back.

I can't find anything in the design whether Vivado or Petalinux in the device tree that would lead to this failure to map the addresses. The driver sees the 0xe0004000 and does the IO resource remap, but obviously it doesn't work.

I guess this part of the design will remain TBD until the main board is available.

BTW, what they asked also is to look into using the same PMOD with 2 devices attached. I.E., with the I2c on 4 Pmod pins of the bottom row  pins 7-12  and a gpio on the top row 0-6, using the appropriate MIO to connect to the PS controllers, but I hadn't even gotten to testing this. When I looked at the GPIO alone under sysfs I was unable to effect a change in the 0/1 status of the inputs. Again as if the register ports were not mapped. Do you think there is some Linux .config setting that I am missing?

But thanks for trying. If something occurs to me I will be sure to post

Sincerely,

James

I may have encountered the same problem with the I2C controller. I am using the I2C c

I may have encountered the same problem with the I2C Controller. I am using a PicoZed and have mapped the SDA and SCL to the MIO pins. It is a bare metal application. I have a scope connected to the SDA and SCL signals and the slave address that was written to the I2C register is not correct on the scope.