update 2:
i pretty much ripped the entire drivers/i2c directory from MTK_APSoC_SDK 5310
and put it in my 4.14 (lol).
after a few small modifications, i still get the same problem.
thus, i think we can rule out kernel changes and that only leaves the
bootloader (??) and the me (y’know, “it’s not the machine, it’s the person
behind it” and all).
i do see that to compile u-boot, there is an rtc folder. makes me curious as to
whether the RALINK devs looked at this for this specific board (882/878).
will do some more investigation when i get some more ideas.
thanks again to andrey for his amasing (lol) guidance.
> On Mar 23, 2018, at 3:51 PM, Gagan Sidhu <br...@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@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@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@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 <br...@mac.com> wrote:
>>
>>
>>> On Mar 23, 2018, at 2:20 PM, Andrey Melnikov <temnota...@gmail.com> wrote:
>>>
>>> 2018-03-23 22:05 GMT+03:00 Gagan Sidhu <br...@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@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@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@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@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...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> In article <3c43c01b-94a6-4a6f-82b6-a81659508...@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@4b {
>>>>>>> compatible = "national, lm92";
>>>>>>> reg = <0x4b>;
>>>>>>>
>>>>>>> };
>>>>>>>
>>>>>>> rtc@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@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.
>>>>>
>>>>
>>
>
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
