UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
10,071 Views
Registered: ‎07-09-2012

RTC support on the Zynq

Jump to solution

Hello,

 

We are trying to make use of the Epson RTC8564 chip to maintain time of day through reboots, etc.  We are using OSL V3.10 Linux.

 

The reference design has this chip connected to the I2C through a I2C switch.  It is apparently at address 4 of the I2C switch based on the dts file.   I don't see any RTC interrupt defined in the .dts file

 

I have a number of questions:

 

1.Has anyone verified that the RTC definitely works on the dev board?  

 

2. The rtc is defined as rtc@54 { compatible ="nxp,pcf8563"; reg = <0x51>; };  What does the 0x51 map to?  Is this the final I2c address?

 

3.  We are not using a I2c switch in our design.  In the original 3.10 zynq-zc702.dts file, the rtc section is embedded in a subsection under the i2c switch.  I assume I should just move the rtc section out of the switch section and delete the switch section as below?

ps7_i2c_0: ps7-i2c@e0004000 {
bus-id = <0>;
clocks = <&clkc 38>;
compatible = "xlnx,ps7-i2c-1.00.a";
i2c-clk = <400000>;
interrupt-parent = <&ps7_scugic_0>;
interrupts = <0 25 4>;
reg = <0xe0004000 0x1000>;
xlnx,has-interrupt = <0x0>;
xlnx,i2c-reset = "MIO 13";
#address-cells = <1>;
#size-cells = <0>;
rtc@54 {
compatible = "nxp,pcf8563";
reg = <0x51>;
};

};

 

4. I assume that since the kernel has an option for the 8563/8564 it handles the direct i2c communications with the chip.  So, if the device tree and kernel are correctly configured, the RTC should work without further programming involvement. Correct?

 

5. The kernel is configured for the Philips pcf8563/Epson RTC8564.  Is compatible = "nxp,pcf8563"; correct for this configuration?

 

6. Should an interrupt be exposed in the DTS file for the RTC?

 

 

Thanks,

 

 

- Dave

 

 

1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
13,815 Views
Registered: ‎11-12-2007

Re: RTC support on the Zynq

Jump to solution

1.Has anyone verified that the RTC definitely works on the dev board?  

 

Yes, I use it consistently on both the ZC702 and ZC706. You will need to manually set the clock with the hwclock command in order to start using it.

 

4. I assume that since the kernel has an option for the 8563/8564 it handles the direct i2c communications with the chip.  So, if the device tree and kernel are correctly configured, the RTC should work without further programming involvement. Correct?

 

Yes, you'll see output regarding the hardware clock in the kernel log during boot. As long as the device is programmed and it hasn't lost battery since the last power-on the driver will read the current time and update automatically.

 

6. Should an interrupt be exposed in the DTS file for the RTC?

 

No, it's not necessary and the driver in the kenrel tree doesn't make use of it.

 

Cheers,

Rob

View solution in original post

7 Replies
Xilinx Employee
Xilinx Employee
10,066 Views
Registered: ‎03-13-2012

Re: RTC support on the Zynq

Jump to solution

Basically all these questions should be answerable by the documentation for the DT bindings (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings ).

 

I guess the bindings for Zynq's I2C controller are probably not in there, so you have to copy that from one of the Zynq dts files. But everything else should be according to documentation and of course your actual I2C topology.

 

The 'reg' property of I2C devices is usually the I2C address, yes.

Your RTC is documented in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/i2c/trivial-devices.txt . For more details you'd have to read through the actual driver https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/rtc/rtc-pcf8563.c and the generic I2C binding descriptions.

0 Kudos
Xilinx Employee
Xilinx Employee
13,816 Views
Registered: ‎11-12-2007

Re: RTC support on the Zynq

Jump to solution

1.Has anyone verified that the RTC definitely works on the dev board?  

 

Yes, I use it consistently on both the ZC702 and ZC706. You will need to manually set the clock with the hwclock command in order to start using it.

 

4. I assume that since the kernel has an option for the 8563/8564 it handles the direct i2c communications with the chip.  So, if the device tree and kernel are correctly configured, the RTC should work without further programming involvement. Correct?

 

Yes, you'll see output regarding the hardware clock in the kernel log during boot. As long as the device is programmed and it hasn't lost battery since the last power-on the driver will read the current time and update automatically.

 

6. Should an interrupt be exposed in the DTS file for the RTC?

 

No, it's not necessary and the driver in the kenrel tree doesn't make use of it.

 

Cheers,

Rob

View solution in original post

Explorer
Explorer
10,058 Views
Registered: ‎07-09-2012

Re: RTC support on the Zynq

Jump to solution

Thanks!  The RTC is up & working.

 

- Dave

0 Kudos
Contributor
Contributor
9,752 Views
Registered: ‎12-24-2013

Re: RTC support on the Zynq

Jump to solution

Hi, dpekin.

 

I have the same problem as you.

 

I use Epson RTC8564 chip on my board without a I2C switch also.

 

I modified my .dts file as below: 

 ps7_i2c_0: ps7-i2c@e0004000 { 
            bus-id = <0>; 
            clocks = <&clkc 38>; 
            compatible = "xlnx,ps7-i2c-1.00.a"; 
            i2c-clk = <400000>; 
            i2c-reset = <&ps7_gpio_0 13 0>; 
            interrupt-parent = <&ps7_scugic_0>; 
            interrupts = <0 25 4>; 
            reg = <0xe0004000 0x1000>; 
            xlnx,has-interrupt = <0x0>; 
 
            #address-cells = <1>; 
            #size-cells = <0>; 

                    rtc@51 { 
                        compatible = "nxp,pcf8563"; 
                        reg = <0x51>; 
                    }; 

        } ;

 

Unfortunately, my RTC still can not work, it shows:

xi2cps e0004000.ps7-i2c: timeout waiting on completion                                                                          
rtc-rx8581 0-0051: Unable to read device flags                                                                                  
cat: read error: Input/output error

 

Could you show me how you solve your rtc problem.

Many thanks.

0 Kudos
Newbie pbhumkar
Newbie
8,664 Views
Registered: ‎07-22-2014

Re: RTC support on the Zynq

Jump to solution

Could you please show me how to set  manuallt the clock with the hwclock command in order to start using it. ?

0 Kudos
Visitor lanek83
Visitor
8,000 Views
Registered: ‎07-23-2014

Re: RTC support on the Zynq

Jump to solution

To add to this discussion, I am trying to get the DS3231 RTC working using PetaLinux 2014.2.

 

Currently the device tree is as follows:

 

ps7_i2c_0: ps7-i2c@e0004000 {
bus-id = <0>;
clock-frequency = <400000>;
clocks = <&clkc 38>;
compatible = "cdns,i2c-r1p10";
interrupt-parent = <&ps7_scugic_0>;
interrupts = <0 25 4>;
reg = <0xe0004000 0x1000>;
xlnx,has-interrupt = <0x0>;
xlnx,i2c-reset = "";
rtc:rtc@68 {
compatible = "dallas,ds1307";
reg = <0x68>;
};
} ;

 

The Cadence I2C driver appears to be working but nothing appears when using the Xilinx I2C driver:

root@zedboard:~# i2cdetect -l
i2c-0 i2c Cadence I2C at e0004000 I2C adapter

 

For both Cadence and Xilinx I2C driver, nothing appears when checking for i2c devices:

 

root@zedboard:~# i2cdetect -r 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

 

What can we try next? Does this indicate that there might be a problem in the firmware/block design? Maybe the i2c clock has not been setup correctly?

0 Kudos
Newbie mjj
Newbie
885 Views
Registered: ‎02-25-2019

Re: RTC support on the Zynq

Jump to solution

You may need to ensure the i2c pins are configured correctly. Something similar to this in your device tree might do the trick (suitably modified for your board design e.g. you will probably need to change the groups, io-standard and bias-* and maybe clock-frequency):

 

 

&pinctrl0 {
        pinctrl_i2c0_default: i2c0-default {
                mux {
                        groups = "i2c0_0_grp";
                        function = "i2c0";
                };
                conf {
                        groups = "i2c0_0_grp";
                        slew-rate = <0>;
                        io-standard = <3>;
                        bias-disable;
                };
        };
        pinctrl_i2c1_default: i2c1-default {
                mux {
                        groups = "i2c1_5_grp";
                        function = "i2c1";
                };
                conf {
                        groups = "i2c1_5_grp";
                        slew-rate = <0>;
                        io-standard = <1>;
                        bias-pullup;    /* external pull-ups not installed! */
                };
        };
};
&i2c0 {
        status = "okay";
        clock-frequency = <400000>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_i2c0_default>;
};
&i2c1 {
        status = "okay";
        clock-frequency = <400000>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_i2c1_default>;
};

(requires your DTS to be based on arch/arm/boot/dts/zynq-7000.dts) ... or you could just ensure your boot code sets the pins up correctly instead.

0 Kudos