From: Josua Mayer <josua@solid-run.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
NXP Linux Team <linux-imx@nxp.com>,
Yazan Shhady <yazan.shhady@solid-run.com>,
Jon Nettleton <jon@solid-run.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: dts: imx6qdl-hummingboard: Add rtc0 and rtc1 aliases to fix hctosys
Date: Mon, 29 Jan 2024 19:26:07 +0000 [thread overview]
Message-ID: <8d5bfef0-ced5-4f3f-a176-707b0dcbd0ea@solid-run.com> (raw)
In-Reply-To: <ZaqIQ7X4/iI3jxtU@shell.armlinux.org.uk>
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"
}
}
}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Josua Mayer <josua@solid-run.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
NXP Linux Team <linux-imx@nxp.com>,
Yazan Shhady <yazan.shhady@solid-run.com>,
Jon Nettleton <jon@solid-run.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: dts: imx6qdl-hummingboard: Add rtc0 and rtc1 aliases to fix hctosys
Date: Mon, 29 Jan 2024 19:26:07 +0000 [thread overview]
Message-ID: <8d5bfef0-ced5-4f3f-a176-707b0dcbd0ea@solid-run.com> (raw)
In-Reply-To: <ZaqIQ7X4/iI3jxtU@shell.armlinux.org.uk>
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"
}
}
}
next prev parent reply other threads:[~2024-01-29 19:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-18 15:01 [PATCH] ARM: dts: imx6qdl-hummingboard: Add rtc0 and rtc1 aliases to fix hctosys Josua Mayer
2024-01-18 15:01 ` Josua Mayer
2024-01-18 15:10 ` Fabio Estevam
2024-01-18 15:10 ` Fabio Estevam
2024-01-18 16:07 ` Russell King (Oracle)
2024-01-18 16:07 ` Russell King (Oracle)
2024-01-19 12:08 ` Josua Mayer
2024-01-19 12:08 ` Josua Mayer
2024-01-19 13:46 ` Josua Mayer
2024-01-19 13:46 ` Josua Mayer
2024-01-19 14:33 ` Russell King (Oracle)
2024-01-19 14:33 ` Russell King (Oracle)
2024-01-29 19:26 ` Josua Mayer [this message]
2024-01-29 19:26 ` Josua Mayer
2024-01-29 22:07 ` Russell King (Oracle)
2024-01-29 22:07 ` Russell King (Oracle)
2024-02-05 9:56 ` Shawn Guo
2024-02-05 9:56 ` Shawn Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d5bfef0-ced5-4f3f-a176-707b0dcbd0ea@solid-run.com \
--to=josua@solid-run.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=jon@solid-run.com \
--cc=kernel@pengutronix.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=yazan.shhady@solid-run.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.