Am 19.01.24 um 15:33 schrieb Russell King (Oracle):
> On Fri, Jan 19, 2024 at 01:46:26PM +0000, Josua Mayer wrote:
>> Am 19.01.24 um 13:07 schrieb Josua Mayer:
>>> Am 18.01.24 um 17:07 schrieb Russell King (Oracle):
>>>> On Thu, Jan 18, 2024 at 04:01:10PM +0100, Josua Mayer wrote:
>>>>> HummingBoard has two RTCs, first integrated within SoC that can be used to
>>>>> wake up from sleep - and a second on the carrier board including back-up
>>>>> battery which is intended for keeping time during power-off.
>>>>>
>>>>> Add aliases for both, ensuring that the battery-backed clock is primary
>>>>> rtc and used by default during boot for restoring system time.
>>>> Given that the snvs RTC isn't battery backed, should we even be enabling
>>>> that in DT?
>>> In imx6qdl.dtsi it is not disabled.
>>> According to Jon it is useful because it can wake up the soc from sleep,
>>> whereas the external rtc can't.
>>>> Also, have you seen any issues such as:
>>>>
>>>> [ 0.933249] rtc-pcf8523 0-0068: failed to set xtal load capacitance: -11
>>>> [ 0.933505] rtc-pcf8523: probe of 0-0068 failed with error -11
>>>>
>>>> which seems to be exhibiting itself on my SolidSense board?
>>> Not on my HummingBoard Gate Rev. 1.4., but indeed on my solidsense
>>> unit too, which is probably same age as yours.
>>> Only tested imx6dl-hummingboard2-emmc-som-v15.dtb,
>>> but solidsense one should make no difference.
>> I was reading control registers 1-3:
>> debian@sr-imx6:~$ sudo i2cget -y -a -f 0 0x68 0x00
>> 0x00
>> debian@sr-imx6:~$ sudo i2cget -y -a -f 0 0x68 0x01
>> 0x00
>> debian@sr-imx6:~$ sudo i2cget -y -a -f 0 0x68 0x02
>> 0x04
>>
>> ^^ This means low voltage on back up battery
> Interesting - in my case, the solidsense has been powered on for months
> (it's my internet router on the boat).
>
> I've rebooted it again today, and this time it seems to have been
> successful, and is using the time from it.
>
>> After a few power-cycles that error went away.
>> Why pcf8523_load_capacitance would ever return EAGAIN I don't see.
>>
>> In any case now that probe succeeded, I read these values:
>> 0x80
>> 0x00
>> 0x04
> For me, after the last reboot, they contain:
> 0x80
> 0x00
> 0x08
>
>> Long story short I don't think the EAGAIN during probe is related
>> to adding aliases.
>> HOWEVER imo pcf8523_probe should return an error when
>> pcf8523_load_capacitance fails.
> I think the real question is where is the EAGAIN coming from and
> why.
I have tried reproducing this on 6.7.0 with imx_v6_v7_defconfig:
I use expect [1] to capture kernel rtc messages during boot,
explicitly overwrite load capacitance bit to ensure
regmap_update_bits in pcf8523_load_capacitance has work
to do during next probe, and finally trigger software reboot.
On HummingBoard-2 I have not seen the issue during 80
reboot cycles, and on solidsense not seen during 25 cycles.
Maybe it needs an almost-all-modconfig kernel?
Or maybe it only happens when the rtc has lost time?
Perhaps I can try disassembling the backup battery ... .
[1]
#!/usr/bin/expect -f
set tty [lindex $argv 0]
set logfile [lindex $argv 1]
set count 0
# log full output to file, but only status messages to stdout
if {$logfile != ""} {
log_file -a $logfile
log_user 0
}
#exec stty -F $tty 115200 raw -clocal -echo -istrip -hup
#spawn -open [open $tty w+]
spawn tio $tty
while {true} {
expect {
-re "Debian GNU/Linux 11 sr-imx6 ttymxc0" {
set count [expr $count + 1]
set time [clock seconds]
set timestr [clock format $time -format "%D %T"]
send_user "\[$timestr\] Successful boots to Linux: $count\n"
}
-re "sr-imx6 login:" {
send "debian\n"
expect -re "Password:"
send "debian\n"
expect -re {debian@sr-imx6:~$}
send "sudo i2cset -f -y 0 0x68 0x00 0x00; sudo reboot\n"
}
-re "password for debian:" {
send "debian\n"
}
-re {\] (rtc-pcf8523.*)\n} {
set matched $expect_out(1,string)
set time [clock seconds]
set timestr [clock format $time -format "%D %T"]
send_user "\[$timestr\] $matched\n"
}
}
}
