[LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)

Gagan Sidhu broly at mac.com
Fri Mar 23 14:51:40 PDT 2018


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.
>>>> 
>>> 
> 




More information about the Lede-dev mailing list