Sorry, you need to enable JavaScript to visit this website.

MicroZed PMOD Zynq PS MIO I2C controller registers unmapped

Unsolved
8 posts / 0 new
james t kennedy's picture
james t kennedy
Junior(0)
MicroZed PMOD Zynq PS MIO I2C controller registers unmapped

The design uses Petalinux OpenAMP primarily as a data engine using the Ethernet port to process data and deliver to the microheader. So the MicroZed is a daughter card on a custom PCB that receives the processed data.
However we are also attempting to use the PMOD to connect to an I2C and a GPIO device.
The standard driver for the Zynq PS I2C controller under PetaLinux is Cadence I2C_cadence which operates the PS I2C controller through its registers.
Well the user level /dev/i2c0 writes were not working, so I added a custom module with the i2c_cadence as the basis and connected it to the I2C0 controller in the device tree to see how the driver was failing.
What I found using debug trace is that the I2C controller registers are not connected to their specified address 0xE0004000. Somehow its addresses on the IOP are not mapped. Regardless of what is written all the R/W registers read 0, and obviously the I2C controller function was not being executed.
Other peripherals on the IOP range of addesses UART, ENET work fine.
I am using Vivado 2016.2 and Petalinux 2016.2. The I2C0 is selected on MIO 14, 15 for SCL and SDA respectively, and the device tree specifies the normal 0xE0004000 as the register address for the controller.
Has anyone encountered this and found their mistake? Or any other suggestions?

zedhed's picture
zedhed
Moderator(22)
RE: 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

james t kennedy's picture
james t kennedy
Junior(0)
Petalinux Zynq PS I2C via MicroZed PMOD

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
 
 

james t kennedy's picture
james t kennedy
Junior(0)
&i2c0 {

&i2c0 {
    clock-frequency = <400000>;
    status = "okay";
};
 
in another dtsi file also generated by petalinux
 

zedhed's picture
zedhed
Moderator(22)
RE: Petalinux Zynq PS I2C via MicroZed PMOD

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

james t kennedy's picture
james t kennedy
Junior(0)
RE: Petalinux Zynq PS I2C via MicroZed PMOD

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
 

pschur's picture
pschur
Junior(0)
I2C

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

pschur's picture
pschur
Junior(0)
I2C Controller Issue

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.