MT7621AT rtc issues (pcf8563)
Gagan Sidhu
broly at mac.com
Tue Apr 10 10:32:09 PDT 2018
hello,
Bblow is an exchange I’ve had with some individuals who are apart of openwrt/linux kernel development.
as alexandre points out, it is likely that the setting of time (even though it is reported as successful) is not operating as-expected, since RTC_RD_TIME is returning an “invalid argument” error.
i was hoping to get some insight as to how this can be fixed. i have tried the i2c-gpio and dts approaches, both of which yielded the same result.
Thanks,
Gagan
> On Apr 9, 2018, at 1:13 PM, Alexandre Belloni <alexandre.belloni at free-electrons.com> wrote:
>
> Hi,
>
> On 23/03/2018 15:53:12-0600, Gagan Sidhu wrote:
>> hello again,
>>
>> so i followed your suggestinos and i did manage to get the gpio/i2c approach working, but it gets no farther than the I2C OF approach.
>>
>> i’ve attached my exchange with the guys at LEDE below, just so you have an idea.
>>
>> it could very well be a change on the RALINK side between 3.x and 4.x, but it seems the pullup lines are being used (?? not an expert here, please do correct me wherever necessary).
>>
>
> Well, I still think writing "succeeds" because the driver doesn't check
> the write and then reading fails because the i2c bus still doesn't work.
>
> You should probably contact Matthias Brugger <matthias.bgg at gmail.com> or
> Sean Wang <sean.wang at mediatek.com> or the
> linux-mediatek at lists.infradead.org mailing list.
>
>>
>> Thanks,
>> Gagan
>>
>>
>>
>>
>>> On Mar 23, 2018, at 3:51 PM, Gagan Sidhu <broly at mac.com> wrote:
>>>
>>> update:
>>>
>>> it seems the pins are supposed to be 11 and 4, and not 3 and 4:
>>>
>>>> i2c-gpio 1e000000.palmbus:i2c-gpio at 900: using pins 11 (SDA) and 4 (SCL)
>>>
>>> this results in the registration of the rtc driver, however the same problem is still there:
>>>
>>>> root at DD-WRT:~# hwclock --verbose --systohc
>>>> hwclock from util-linux 2.32
>>>> System Time: 70.107290
>>>> Trying to open: /dev/rtc0
>>>> Using the rtc interface to the clock.
>>>> Assuming hardware clock is kept in UTC time.
>>>> 70.500018 is close enough to 70.500000 (0.000018 < 0.001000)
>>>> Set RTC to 70 (70 + 0; refsystime = 70.000000)
>>>> Setting Hardware Clock to 00:01:10 = 70 seconds since 1969
>>>> ioctl(RTC_SET_TIME) was successful.
>>>> Not adjusting drift factor because the --update-drift option was not used.
>>>> New /etc/adjtime data:
>>>> 0.000000 70 0.000000
>>>> 70
>>>> UTC
>>>
>>>> root at DD-WRT:~# hwclock --verbose --hctosys
>>>> hwclock from util-linux 2.32
>>>> System Time: 73.917335
>>>> Trying to open: /dev/rtc0
>>>> Using the rtc interface to the clock.
>>>> Last drift adjustment done at 70 seconds after 1969
>>>> Last calibration done at 70 seconds after 1969
>>>> Hardware clock is on UTC time
>>>> Assuming hardware clock is kept in UTC time.
>>>> Waiting for clock tick...
>>>> ioctl(3, RTC_UIE_ON, 0): Invalid argument
>>>> Waiting in loop for time from /dev/rtc0 to change
>>>> hwclock: ioctl(RTC_RD_TIME) to /dev/rtc0 to read the time failed: Invalid argument
>>>> ...synchronization failed
>>>
>>>
>>> as andrey alluded to, i think there is something up with the changes between 3.x and 4.x that is hindering the usage of i2c devices.
>>>
>>> i am happy that i can confirm the SDA/SDL approach does not change anything in comparison to the (canonical) OF dts.
>>>
>>> i’ll forward this correspondence to Alexandre to see if he has any additional insights.
>>>
>>> these are the combinations i tried for SDA/SDL:
>>> 3/4 (failure)
>>> 4/11 (same as OF I2C approach, no RTC_RD_TIME)
>>> 4/5 (same as the above).
>>>
>>>
>>> thx
>>>
>>>
>>>
>>>> On Mar 23, 2018, at 3:16 PM, Gagan Sidhu <broly at mac.com> wrote:
>>>>
>>>>
>>>>> On Mar 23, 2018, at 2:20 PM, Andrey Melnikov <temnota.am at gmail.com> wrote:
>>>>>
>>>>> 2018-03-23 22:05 GMT+03:00 Gagan Sidhu <broly at mac.com>:
>>>>>> so there are two cases.
>>>>>>
>>>>>> 1. the case of the i2c-mt7621 driver, i do exactly what you state:
>>>>>> -remove “i2c” from pinctrl in the dts, and set CONFIG_I2C_MT7621=y
>>>>>> -in this case, the driver is half-working, but is unable to read the rtc.
>>>>>
>>>>> I2C speed checked?
>>>> yeah, it always shows:
>>>> i2c-mt7621 1e000900.i2c: clock 100KHz, re-start not support
>>>> during boot
>>>>>
>>>>>> 2. the case of the i2c-gpio driver. i:
>>>>>> -enable CONFIG_I2C_GPIO=y,
>>>>>> -include i2c-gpio inside the palmbus at 1E000000 { … node
>>>>>> -rename “i2c-mt7621” in mt7621.dtsi to “i2c-gpio”
>>>>>
>>>>> Hmm. Try build & load i2c-gpio-custom with args bus0=0,SDA-PIN,SCL-PIN
>>>>> and check.
>>>>
>>>> thank you for this suggestion.
>>>> just want to add that i forgot to add a “@900” at the end of “i2c-gpio” (so that the address is correct).
>>>>
>>>> i downloaded https://github.com/lede-project/source/tree/master/package/kernel/i2c-gpio-custom/src
>>>> after doing this, there is more hope but still nothing concrete.
>>>>
>>>> i first tried i2c-gpio-custom (i understand there are arguments required, so please bear with me) as a kernel driver and this is what i get:
>>>>
>>>> i2c-gpio 1e000000.palmbus:i2c-gpio at 900: using pins 3 (SDA) and 4 (SCL)
>>>> Custom GPIO-based I2C driver version 0.1.1
>>>> i2c-gpio-custom: no bus parameter(s) specified
>>>>
>>>> which results in failure to register the rtc, but at least it tries:
>>>>
>>>> rtc-pcf8563 0-0051: pcf8563_write_block_data: err=-6 addr=0e, data=03
>>>> rtc-pcf8563 0-0051: pcf8563_probe: write error
>>>> rtc-pcf8563: probe of 0-0051 failed with error -5
>>>>
>>>> now, as a module, assuming i replace SDA-PIN and SCL-PIN with 3 and 4 (values from gpios in i2c-gpio node) i get:
>>>>
>>>> root at DD-WRT:~# insmod i2c-gpio-custom.ko bus0=0,3,4
>>>> Jan 1 01:01:19 DD-WRT kernel: Custom GPIO-based I2C driver version 0.1.1
>>>> Jan 1 01:01:19 DD-WRT kernel: i2c-gpio: probe of i2c-gpio.0 failed with error -16
>>>>
>>>> root at DD-WRT:~# insmod i2c-gpio-custom.ko bus0=1,3,4
>>>> Jan 1 01:03:02 DD-WRT kernel: Custom GPIO-based I2C driver version 0.1.1
>>>> Jan 1 01:03:02 DD-WRT kernel: i2c-gpio: probe of i2c-gpio.1 failed with error -16
>>>>
>>>> aghhhhh!! so close ah.
>>>> need the rtc ah for pam_lastlog ah
>>>> greatly amplifies desktop experience on router ah
>>>> must have ah (lol)
>>>>
>>>>>
>>>>>> i followed your suggestion and removed i2c from pinctrl in the dts, but the i2c-gpio driver goes undetected.
>>>>>>
>>>>>> does anyone running lede/openwrt on an mt7621 have a functional rtc?
>>>>> I'm running it on mikrotik rb750gr3 without any I2C. But I have other
>>>>> device on mt7620 with I2C and have same problem - can't see specific
>>>>> controller on I2C bus. Original firmware (based on ralink SDK kernel
>>>>> 3.10.14-x) working. But I have not time to deep check this now.
>>>> no worries. i was wondering if it was something effecting all RALINK devices. it must be.
>>>> i don’t think the driver is the problem, but something to do with the changes in 3.x and 4.x for i2c.
>>>>
>>>>>
>>>>>>> On Mar 23, 2018, at 3:36 AM, Andrey Jr. Melnikov <temnota.am at gmail.com> wrote:
>>>>>>>
>>>>>>> In article <3C43C01B-94A6-4A6F-82B6-A81659508396 at mac.com> you wrote:
>>>>>>>> hi guys,
>>>>>>>
>>>>>>>> sorry for bumping this thread, but i found Sven???s approach interesting.
>>>>>>>
>>>>>>>> in 4.x, it does not seem i can simply enable CONFIG_I2C_GPIO=y, add the i2c-gpio node:
>>>>>>>
>>>>>>>>> i2c-gpio {
>>>>>>>>> compatible = "i2c-gpio";
>>>>>>>>> gpios = <&gpio0 3 0
>>>>>>>>> &gpio0 4 0>;
>>>>>>>>> #address-cells=<1>;
>>>>>>>>> #size-cells = <0>;
>>>>>>>>> hwmon at 4b {
>>>>>>>>> compatible = "national, lm92";
>>>>>>>>> reg = <0x4b>;
>>>>>>>>>
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> rtc at 51 {
>>>>>>>>> compatible = "nxp,pcf8563";
>>>>>>>>> reg = <0x51>;
>>>>>>>>> #clock-cells = <0>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> };
>>>>>>>
>>>>>>>
>>>>>>>> and modify the pinctrl node accordingly:
>>>>>>>
>>>>>>>>> pinctrl {
>>>>>>>>> state_default: pinctrl0 {
>>>>>>>>> gpio {
>>>>>>>>> ralink,group = "rgmii2", "uart2","uart3","wdt","i2c","jtag";
>>>>>>>>> ralink,function = "gpio";
>>>>>>>>> };
>>>>>>>>> };
>>>>>>>>> };
>>>>>>>
>>>>>>> adding "i2c" to gpio group simply make it unusable for kernel - it's export all named pins as plain gpio. If you want
>>>>>>> to use i2c kernel driver - remove "i2c" from gpio export.
>>>>>>>
>>>>>>>> in DIR882.dts (inherits from mt7621.dtsi), where i add ???i2c-gpio??? to the i2c entry in mt7621.dtsi as follows:
>>>>>>>
>>>>>>>>> i2c: i2c at 900 {
>>>>>>>>> compatible = "i2c-gpio";
>>>>>>>>> reg = <0x900 0x100>;
>>>>>>>>>
>>>>>>>>> clocks = <&sysclock>;
>>>>>>>>>
>>>>>>>>> resets = <&rstctrl 16>;
>>>>>>>>> reset-names = "i2c";
>>>>>>>>>
>>>>>>>>> #address-cells = <1>;
>>>>>>>>> #size-cells = <0>;
>>>>>>>>>
>>>>>>>>> status = "disabled";
>>>>>>>>>
>>>>>>>>> pinctrl-names = "default";
>>>>>>>>> pinctrl-0 = <&i2c_pins>;
>>>>>>>>> }
>>>>>>>
>>>>>>>> it does not work at all.
>>>>>>>
>>>>>>>> i really want a functional rtc lol.
>>>>>>>
>>>>>>>> my router is not connected to the internet so if the rtc can hold the time for a second after reset, that should be enough since resetting doesn???t cut power.
>>>>>>>
>>>>>>>> i spoke with Alexandre Belloni who has done a lot of work on the linux rtc, and he says we are missing the SDA/SDL PULLUP mechanism. this makes sense.
>>>>>>>
>>>>>>>> the question is: what needs work in order to have a fully functional rtc? as-is, i am only able to write to the clock but not able to read from it, which suggests i need to incorporate the SDA/SDL pins somehow.
>>>>>>>
>>>>>>>> any tips would be great.
>>>>>>>
>>>>>>
>>>>
>>>
>>
>
> --
> Alexandre Belloni, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
More information about the Linux-mediatek
mailing list