* TS-219 RTC issue with Debian Buster
@ 2019-07-23 15:30 Oliver Hartkopp
2019-07-23 16:12 ` Andrew Lunn
2019-07-23 19:06 ` Uwe Kleine-König
0 siblings, 2 replies; 16+ messages in thread
From: Oliver Hartkopp @ 2019-07-23 15:30 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Andrew Lunn, tbm
Hi all,
I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell.
They use dtbs/4.19.0-5-marvell/./kirkwood-ts219-6282.dtb
Unfortunately the RTC doesn't seem to work.
root@xxxxx:~# hwclock -v --test
hwclock from util-linux 2.33.1
System Time: 1563296223.425648
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1563291472 seconds after 1969
Last calibration done at 1563291472 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
...synchronization failed
Test mode: nothing was changed.
With strace the clock tick problem looks like this:
write(1, "Waiting for clock tick...\n", 26Waiting for clock tick...
) = 26
ioctl(4, RTC_UIE_ON) = 0
_newselect(5, [4], NULL, NULL, {tv_sec=10, tv_usec=0}) = 0 (Timeout)
write(2, "hwclock: ", 9hwclock: ) = 9
write(2, "select() to /dev/rtc0 to wait fo"..., 54select() to /dev/rtc0
to wait for clock tick timed out) = 54
write(2, "\n", 1) = 1
ioctl(4, PHN_NOT_OH or RTC_UIE_OFF) = 0
It looks the same with
# hwclock --hctosys
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
I wonder whether the problem comes from a missing interrupt assignment
rtc: rtc@10300 {
compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc";
reg = <0x10300 0x20>;
interrupts = <53>; <- HERE!?!
clocks = <&gate_clk 7>;
};
... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!?
In /proc/interrupts there's no rtc assigned to an interrupt 53.
Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries
works well and setting the date/time via "hwclock --systohc" does its
job too. So I2C and the rtc_s35390a driver seem to work so far.
Any ideas why hwclock fails to work properly?
Best regards,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: TS-219 RTC issue with Debian Buster 2019-07-23 15:30 TS-219 RTC issue with Debian Buster Oliver Hartkopp @ 2019-07-23 16:12 ` Andrew Lunn 2019-07-23 17:31 ` Oliver Hartkopp 2019-07-23 19:06 ` Uwe Kleine-König 1 sibling, 1 reply; 16+ messages in thread From: Andrew Lunn @ 2019-07-23 16:12 UTC (permalink / raw) To: Oliver Hartkopp; +Cc: tbm, linux-arm-kernel On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: > Hi all, > > I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. Hi Oliver Did the same test work with older Debians? > I wonder whether the problem comes from a missing interrupt assignment > > rtc: rtc@10300 { > compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; > reg = <0x10300 0x20>; > interrupts = <53>; <- HERE!?! > clocks = <&gate_clk 7>; > }; > > ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? > > In /proc/interrupts there's no rtc assigned to an interrupt 53. There is code in the driver to request this interrupt. Do you see an error message like: interrupt not available. > Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries works > well and setting the date/time via "hwclock --systohc" does its job too. So > I2C and the rtc_s35390a driver seem to work so far. Now i'm confused. I don't see any mention of s35390a for any TS devices. Some kirkwood machines do make use of an external RTC, not the built in. But not this machine, as far as i know. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 16:12 ` Andrew Lunn @ 2019-07-23 17:31 ` Oliver Hartkopp 2019-07-23 17:56 ` Oliver Hartkopp 0 siblings, 1 reply; 16+ messages in thread From: Oliver Hartkopp @ 2019-07-23 17:31 UTC (permalink / raw) To: Andrew Lunn; +Cc: tbm, linux-arm-kernel Hi Andrew, On 23.07.19 18:12, Andrew Lunn wrote: > On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: >> I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. > > Hi Oliver > > Did the same test work with older Debians? > I'm not really sure when it happened, as I was using the 'testing' release which now lead to Buster. I have no clear point where to look. Just detected some boot delay and looked into the sysctl log wich moved the clock forward based on fact, that the installed binaries where younger than the system clock. %-( >> I wonder whether the problem comes from a missing interrupt assignment >> >> rtc: rtc@10300 { >> compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; >> reg = <0x10300 0x20>; >> interrupts = <53>; <- HERE!?! >> clocks = <&gate_clk 7>; >> }; >> >> ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? >> >> In /proc/interrupts there's no rtc assigned to an interrupt 53. > > There is code in the driver to request this interrupt. Do you see an > error message like: > > interrupt not available. > No. >> Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries works >> well and setting the date/time via "hwclock --systohc" does its job too. So >> I2C and the rtc_s35390a driver seem to work so far. > > Now i'm confused. I don't see any mention of s35390a for any TS > devices. Some kirkwood machines do make use of an external RTC, not > the built in. But not this machine, as far as i know. I snipped some dmesg log pointing to the machine & clock/rtc: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.19.0-5-marvell (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 Debian 4.19.37-5 (2019-06-19) [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: QNAP TS219 family (..) [ 0.000000] clocksource: orion_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns [ 0.000006] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns [ 0.000030] Switching to timer-based delay loop, resolution 5ns [ 0.000099] Calibrating delay loop (skipped), value calculated using timer frequency.. 400.00 BogoMIPS (lpj=800000) [ 0.000117] pid_max: default: 32768 minimum: 301 [ 0.000329] Security Framework initialized [ 0.000344] Yama: disabled by default; enable with sysctl kernel.yama.* [ 0.000427] AppArmor: AppArmor initialized [ 0.000528] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000544] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.001288] CPU: Testing write buffer coherency: ok [ 0.002027] Setting up static identity map for 0x8200 - 0x823c [ 0.002207] mvebu-soc-id: MVEBU SoC ID=0x6282, Rev=0x0 [ 0.003536] devtmpfs: initialized [ 0.006261] VFP support v0.3: not present [ 0.006378] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns (..) [ 1.198026] hctosys: unable to open rtc device (rtc0) [ 1.205324] Freeing unused kernel memory: 312K [ 1.209804] This architecture does not have kernel memory protection. [ 1.216276] Run /init as init process [ 1.299536] random: fast init done [ 1.581741] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0 (..) [ 11.395565] rtc-mv f1010300.rtc: internal RTC not ticking I got the information from Martin Michlmayr's Quap Debian pages: http://www.cyrius.com/debian/kirkwood/qnap/ts-219/status/ http://www.cyrius.com/debian/kirkwood/qnap/ts-119/status/ RTC: Supported in the kernel by the rtc-s35390a module Thanks for your help! Best, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 17:31 ` Oliver Hartkopp @ 2019-07-23 17:56 ` Oliver Hartkopp 2019-07-23 18:30 ` Oliver Hartkopp 2019-07-23 21:07 ` Russell King - ARM Linux admin 0 siblings, 2 replies; 16+ messages in thread From: Oliver Hartkopp @ 2019-07-23 17:56 UTC (permalink / raw) To: Andrew Lunn; +Cc: tbm, linux-arm-kernel I just found an older log booting a Linux 4.9 where it was ok: Jan 6 20:57:03 sam kernel: [ 0.000000] Booting Linux on physical CPU 0x0 Jan 6 20:57:03 sam kernel: [ 0.000000] Linux version 4.9.0-4-marvell (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 Debian 4.9.51-1 (2017-09-28) Jan 6 20:57:03 sam kernel: [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f Jan 6 20:57:03 sam kernel: [ 0.000000] CPU: VIVT data cache, VIVT instruction cache Jan 6 20:57:03 sam kernel: [ 0.000000] OF: fdt:Machine model: QNAP TS219 family (..) Jan 6 20:57:03 sam kernel: [ 1.052175] mousedev: PS/2 mouse device common for all mice Jan 6 20:57:03 sam kernel: [ 2.090654] rtc-mv f1010300.rtc: internal RTC not ticking Jan 6 20:57:03 sam kernel: [ 2.096219] i2c /dev entries driver Jan 6 20:57:03 sam kernel: [ 2.101859] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0 Jan 6 20:57:03 sam kernel: [ 2.109296] ledtrig-cpu: registered to indicate activity on CPUs Jan 6 20:57:03 sam kernel: [ 2.115640] NET: Registered protocol family 17 Jan 6 20:57:03 sam kernel: [ 2.120536] registered taskstats version 1 Jan 6 20:57:03 sam kernel: [ 2.124695] zswap: loaded using pool lzo/zbud Jan 6 20:57:03 sam kernel: [ 2.129852] random: fast init done Jan 6 20:57:03 sam kernel: [ 2.133441] rtc-s35390a 0-0030: setting system clock to 2018-01-06 19:56:53 UTC (1515268613) Jan 6 20:57:03 sam kernel: [ 2.143039] Freeing unused kernel memory: 296K Just wondering whether this a kernel problem or a systemd thing. At least the rtc-s35390a module is loaded before is is accessed. Regards, Oliver > Hi Andrew, > > On 23.07.19 18:12, Andrew Lunn wrote: >> On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: > >>> I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. >> >> Hi Oliver >> >> Did the same test work with older Debians? >> > > I'm not really sure when it happened, as I was using the 'testing' > release which now lead to Buster. I have no clear point where to look. > Just detected some boot delay and looked into the sysctl log wich moved > the clock forward based on fact, that the installed binaries where > younger than the system clock. %-( > >>> I wonder whether the problem comes from a missing interrupt assignment >>> >>> rtc: rtc@10300 { >>> compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; >>> reg = <0x10300 0x20>; >>> interrupts = <53>; <- HERE!?! >>> clocks = <&gate_clk 7>; >>> }; >>> >>> ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? >>> >>> In /proc/interrupts there's no rtc assigned to an interrupt 53. >> >> There is code in the driver to request this interrupt. Do you see an >> error message like: >> >> interrupt not available. >> > > No. > >>> Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries >>> works >>> well and setting the date/time via "hwclock --systohc" does its job >>> too. So >>> I2C and the rtc_s35390a driver seem to work so far. >> >> Now i'm confused. I don't see any mention of s35390a for any TS >> devices. Some kirkwood machines do make use of an external RTC, not >> the built in. But not this machine, as far as i know. > > I snipped some dmesg log pointing to the machine & clock/rtc: > > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 4.19.0-5-marvell > (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 > Debian 4.19.37-5 (2019-06-19) > [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), > cr=0005397f > [ 0.000000] CPU: VIVT data cache, VIVT instruction cache > [ 0.000000] OF: fdt: Machine model: QNAP TS219 family > > (..) > > [ 0.000000] clocksource: orion_clocksource: mask: 0xffffffff > max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns > [ 0.000006] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps > every 10737418237ns > [ 0.000030] Switching to timer-based delay loop, resolution 5ns > [ 0.000099] Calibrating delay loop (skipped), value calculated using > timer frequency.. 400.00 BogoMIPS (lpj=800000) > [ 0.000117] pid_max: default: 32768 minimum: 301 > [ 0.000329] Security Framework initialized > [ 0.000344] Yama: disabled by default; enable with sysctl kernel.yama.* > [ 0.000427] AppArmor: AppArmor initialized > [ 0.000528] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) > [ 0.000544] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 > bytes) > [ 0.001288] CPU: Testing write buffer coherency: ok > [ 0.002027] Setting up static identity map for 0x8200 - 0x823c > [ 0.002207] mvebu-soc-id: MVEBU SoC ID=0x6282, Rev=0x0 > [ 0.003536] devtmpfs: initialized > [ 0.006261] VFP support v0.3: not present > [ 0.006378] clocksource: jiffies: mask: 0xffffffff max_cycles: > 0xffffffff, max_idle_ns: 7645041785100000 ns > > (..) > > [ 1.198026] hctosys: unable to open rtc device (rtc0) > [ 1.205324] Freeing unused kernel memory: 312K > [ 1.209804] This architecture does not have kernel memory protection. > [ 1.216276] Run /init as init process > [ 1.299536] random: fast init done > [ 1.581741] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0 > > (..) > > [ 11.395565] rtc-mv f1010300.rtc: internal RTC not ticking > > I got the information from Martin Michlmayr's Quap Debian pages: > http://www.cyrius.com/debian/kirkwood/qnap/ts-219/status/ > http://www.cyrius.com/debian/kirkwood/qnap/ts-119/status/ > > RTC: Supported in the kernel by the rtc-s35390a module > > Thanks for your help! > > Best, > Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 17:56 ` Oliver Hartkopp @ 2019-07-23 18:30 ` Oliver Hartkopp 2019-07-23 19:05 ` Oliver Hartkopp 2019-07-23 22:15 ` Andrew Lunn 2019-07-23 21:07 ` Russell King - ARM Linux admin 1 sibling, 2 replies; 16+ messages in thread From: Oliver Hartkopp @ 2019-07-23 18:30 UTC (permalink / raw) To: Andrew Lunn; +Cc: tbm, linux-arm-kernel Sorry for answering myself again .. After installing the 4.9.0-4-marvell kernel (from old stable Stretch) on my Debian Buster system it works like before: [ 1.101214] mousedev: PS/2 mouse device common for all mice [ 2.123021] rtc-mv f1010300.rtc: internal RTC not ticking [ 2.128592] i2c /dev entries driver [ 2.133933] random: fast init done [ 2.137746] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0 [ 2.145186] ledtrig-cpu: registered to indicate activity on CPUs [ 2.151518] NET: Registered protocol family 17 [ 2.156398] registered taskstats version 1 [ 2.160561] zswap: loaded using pool lzo/zbud [ 2.165913] rtc-s35390a 0-0030: setting system clock to 2019-07-23 18:16:18 UTC (1563905778) [ 2.175514] Freeing unused kernel memory: 296K So the system time is set correctly BUT I wonder WHO is setting the clock here. Seems to be done inside the kernel?!? # hwclock --show hwclock: select() to /dev/rtc0 to wait for clock tick timed out is still not working. Maybe it never worked but with Linux 4.19 the problem shows up ... On 23.07.19 19:56, Oliver Hartkopp wrote: > I just found an older log booting a Linux 4.9 where it was ok: > > Jan 6 20:57:03 sam kernel: [ 0.000000] Booting Linux on physical CPU > 0x0 > Jan 6 20:57:03 sam kernel: [ 0.000000] Linux version 4.9.0-4-marvell > (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian > 6.3.0-18) ) #1 Debian 4.9.51-1 (2017-09-28) > Jan 6 20:57:03 sam kernel: [ 0.000000] CPU: Feroceon 88FR131 > [56251311] revision 1 (ARMv5TE), cr=0005397f > Jan 6 20:57:03 sam kernel: [ 0.000000] CPU: VIVT data cache, VIVT > instruction cache > Jan 6 20:57:03 sam kernel: [ 0.000000] OF: fdt:Machine model: QNAP > TS219 family > > (..) > > Jan 6 20:57:03 sam kernel: [ 1.052175] mousedev: PS/2 mouse device > common for all mice > Jan 6 20:57:03 sam kernel: [ 2.090654] rtc-mv f1010300.rtc: internal > RTC not ticking > Jan 6 20:57:03 sam kernel: [ 2.096219] i2c /dev entries driver > Jan 6 20:57:03 sam kernel: [ 2.101859] rtc-s35390a 0-0030: rtc core: > registered rtc-s35390a as rtc0 > Jan 6 20:57:03 sam kernel: [ 2.109296] ledtrig-cpu: registered to > indicate activity on CPUs > Jan 6 20:57:03 sam kernel: [ 2.115640] NET: Registered protocol > family 17 > Jan 6 20:57:03 sam kernel: [ 2.120536] registered taskstats version 1 > Jan 6 20:57:03 sam kernel: [ 2.124695] zswap: loaded using pool > lzo/zbud > Jan 6 20:57:03 sam kernel: [ 2.129852] random: fast init done > Jan 6 20:57:03 sam kernel: [ 2.133441] rtc-s35390a 0-0030: setting > system clock to 2018-01-06 19:56:53 UTC (1515268613) > Jan 6 20:57:03 sam kernel: [ 2.143039] Freeing unused kernel memory: > 296K > > Just wondering whether this a kernel problem or a systemd thing. > > At least the rtc-s35390a module is loaded before is is accessed. > > Regards, > Oliver > >> Hi Andrew, >> >> On 23.07.19 18:12, Andrew Lunn wrote: >>> On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: >> >>>> I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. >>> >>> Hi Oliver >>> >>> Did the same test work with older Debians? >>> >> >> I'm not really sure when it happened, as I was using the 'testing' >> release which now lead to Buster. I have no clear point where to look. >> Just detected some boot delay and looked into the sysctl log wich >> moved the clock forward based on fact, that the installed binaries >> where younger than the system clock. %-( >> >>>> I wonder whether the problem comes from a missing interrupt assignment >>>> >>>> rtc: rtc@10300 { >>>> compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; >>>> reg = <0x10300 0x20>; >>>> interrupts = <53>; <- HERE!?! >>>> clocks = <&gate_clk 7>; >>>> }; >>>> >>>> ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? >>>> >>>> In /proc/interrupts there's no rtc assigned to an interrupt 53. >>> >>> There is code in the driver to request this interrupt. Do you see an >>> error message like: >>> >>> interrupt not available. >>> >> >> No. >> >>>> Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries >>>> works >>>> well and setting the date/time via "hwclock --systohc" does its job >>>> too. So >>>> I2C and the rtc_s35390a driver seem to work so far. >>> >>> Now i'm confused. I don't see any mention of s35390a for any TS >>> devices. Some kirkwood machines do make use of an external RTC, not >>> the built in. But not this machine, as far as i know. >> >> I snipped some dmesg log pointing to the machine & clock/rtc: >> >> [ 0.000000] Booting Linux on physical CPU 0x0 >> [ 0.000000] Linux version 4.19.0-5-marvell >> (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) >> #1 Debian 4.19.37-5 (2019-06-19) >> [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), >> cr=0005397f >> [ 0.000000] CPU: VIVT data cache, VIVT instruction cache >> [ 0.000000] OF: fdt: Machine model: QNAP TS219 family >> >> (..) >> >> [ 0.000000] clocksource: orion_clocksource: mask: 0xffffffff >> max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns >> [ 0.000006] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps >> every 10737418237ns >> [ 0.000030] Switching to timer-based delay loop, resolution 5ns >> [ 0.000099] Calibrating delay loop (skipped), value calculated >> using timer frequency.. 400.00 BogoMIPS (lpj=800000) >> [ 0.000117] pid_max: default: 32768 minimum: 301 >> [ 0.000329] Security Framework initialized >> [ 0.000344] Yama: disabled by default; enable with sysctl >> kernel.yama.* >> [ 0.000427] AppArmor: AppArmor initialized >> [ 0.000528] Mount-cache hash table entries: 1024 (order: 0, 4096 >> bytes) >> [ 0.000544] Mountpoint-cache hash table entries: 1024 (order: 0, >> 4096 bytes) >> [ 0.001288] CPU: Testing write buffer coherency: ok >> [ 0.002027] Setting up static identity map for 0x8200 - 0x823c >> [ 0.002207] mvebu-soc-id: MVEBU SoC ID=0x6282, Rev=0x0 >> [ 0.003536] devtmpfs: initialized >> [ 0.006261] VFP support v0.3: not present >> [ 0.006378] clocksource: jiffies: mask: 0xffffffff max_cycles: >> 0xffffffff, max_idle_ns: 7645041785100000 ns >> >> (..) >> >> [ 1.198026] hctosys: unable to open rtc device (rtc0) >> [ 1.205324] Freeing unused kernel memory: 312K >> [ 1.209804] This architecture does not have kernel memory protection. >> [ 1.216276] Run /init as init process >> [ 1.299536] random: fast init done >> [ 1.581741] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as >> rtc0 >> >> (..) >> >> [ 11.395565] rtc-mv f1010300.rtc: internal RTC not ticking >> >> I got the information from Martin Michlmayr's Quap Debian pages: >> http://www.cyrius.com/debian/kirkwood/qnap/ts-219/status/ >> http://www.cyrius.com/debian/kirkwood/qnap/ts-119/status/ >> >> RTC: Supported in the kernel by the rtc-s35390a module >> >> Thanks for your help! >> >> Best, >> Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 18:30 ` Oliver Hartkopp @ 2019-07-23 19:05 ` Oliver Hartkopp 2019-07-23 22:15 ` Andrew Lunn 1 sibling, 0 replies; 16+ messages in thread From: Oliver Hartkopp @ 2019-07-23 19:05 UTC (permalink / raw) To: Andrew Lunn; +Cc: tbm, linux-arm-kernel Ok, I think I finally found the problem: The fact that # hwclock --show leads to hwclock: select() to /dev/rtc0 to wait for clock tick timed out seems to be a normal behaviour as hwclock executes an ioctl(4, RTC_UIE_ON) and linux/drivers/rtc/rtc-s35390a.c tells us in s35390a_probe() /* supports per-minute alarms only, therefore set uie_unsupported */ s35390a->rtc->uie_unsupported = 1; So hwclock *never* worked to read out the time on this machine. The reason why Linux 4.9 worked and is setting the system clock is because the rtc-s35390a driver was compiled built-in and NOT as a module. Therefore the rtc driver emerges right after the i2c driver and the hctosys call from linux/drivers/rtc/hctosys.c successfully sets the clock before system init. 4.19.0-5-marvell -> CONFIG_RTC_DRV_S35390A=m (fails) 4.9.0-4-marvell -> CONFIG_RTC_DRV_S35390A=y (works) So I need to file a Debian bug to fix the kernel config. Thanks for listening :-) Best regards, Oliver On 23.07.19 20:30, Oliver Hartkopp wrote: > Sorry for answering myself again .. > > After installing the 4.9.0-4-marvell kernel (from old stable Stretch) on > my Debian Buster system it works like before: > > [ 1.101214] mousedev: PS/2 mouse device common for all mice > [ 2.123021] rtc-mv f1010300.rtc: internal RTC not ticking > [ 2.128592] i2c /dev entries driver > [ 2.133933] random: fast init done > [ 2.137746] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0 > [ 2.145186] ledtrig-cpu: registered to indicate activity on CPUs > [ 2.151518] NET: Registered protocol family 17 > [ 2.156398] registered taskstats version 1 > [ 2.160561] zswap: loaded using pool lzo/zbud > [ 2.165913] rtc-s35390a 0-0030: setting system clock to 2019-07-23 > 18:16:18 UTC (1563905778) > [ 2.175514] Freeing unused kernel memory: 296K > > So the system time is set correctly BUT I wonder WHO is setting the > clock here. Seems to be done inside the kernel?!? > > # hwclock --show > hwclock: select() to /dev/rtc0 to wait for clock tick timed out > > is still not working. Maybe it never worked but with Linux 4.19 the > problem shows up ... > > > > On 23.07.19 19:56, Oliver Hartkopp wrote: >> I just found an older log booting a Linux 4.9 where it was ok: >> >> Jan 6 20:57:03 sam kernel: [ 0.000000] Booting Linux on physical >> CPU 0x0 >> Jan 6 20:57:03 sam kernel: [ 0.000000] Linux version >> 4.9.0-4-marvell (debian-kernel@lists.debian.org) (gcc version 6.3.0 >> 20170516 (Debian 6.3.0-18) ) #1 Debian 4.9.51-1 (2017-09-28) >> Jan 6 20:57:03 sam kernel: [ 0.000000] CPU: Feroceon 88FR131 >> [56251311] revision 1 (ARMv5TE), cr=0005397f >> Jan 6 20:57:03 sam kernel: [ 0.000000] CPU: VIVT data cache, VIVT >> instruction cache >> Jan 6 20:57:03 sam kernel: [ 0.000000] OF: fdt:Machine model: QNAP >> TS219 family >> >> (..) >> >> Jan 6 20:57:03 sam kernel: [ 1.052175] mousedev: PS/2 mouse device >> common for all mice >> Jan 6 20:57:03 sam kernel: [ 2.090654] rtc-mv f1010300.rtc: >> internal RTC not ticking >> Jan 6 20:57:03 sam kernel: [ 2.096219] i2c /dev entries driver >> Jan 6 20:57:03 sam kernel: [ 2.101859] rtc-s35390a 0-0030: rtc >> core: registered rtc-s35390a as rtc0 >> Jan 6 20:57:03 sam kernel: [ 2.109296] ledtrig-cpu: registered to >> indicate activity on CPUs >> Jan 6 20:57:03 sam kernel: [ 2.115640] NET: Registered protocol >> family 17 >> Jan 6 20:57:03 sam kernel: [ 2.120536] registered taskstats version 1 >> Jan 6 20:57:03 sam kernel: [ 2.124695] zswap: loaded using pool >> lzo/zbud >> Jan 6 20:57:03 sam kernel: [ 2.129852] random: fast init done >> Jan 6 20:57:03 sam kernel: [ 2.133441] rtc-s35390a 0-0030: setting >> system clock to 2018-01-06 19:56:53 UTC (1515268613) >> Jan 6 20:57:03 sam kernel: [ 2.143039] Freeing unused kernel >> memory: 296K >> >> Just wondering whether this a kernel problem or a systemd thing. >> >> At least the rtc-s35390a module is loaded before is is accessed. >> >> Regards, >> Oliver >> >>> Hi Andrew, >>> >>> On 23.07.19 18:12, Andrew Lunn wrote: >>>> On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: >>> >>>>> I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. >>>> >>>> Hi Oliver >>>> >>>> Did the same test work with older Debians? >>>> >>> >>> I'm not really sure when it happened, as I was using the 'testing' >>> release which now lead to Buster. I have no clear point where to >>> look. Just detected some boot delay and looked into the sysctl log >>> wich moved the clock forward based on fact, that the installed >>> binaries where younger than the system clock. %-( >>> >>>>> I wonder whether the problem comes from a missing interrupt assignment >>>>> >>>>> rtc: rtc@10300 { >>>>> compatible = "marvell,kirkwood-rtc", >>>>> "marvell,orion-rtc"; >>>>> reg = <0x10300 0x20>; >>>>> interrupts = <53>; <- HERE!?! >>>>> clocks = <&gate_clk 7>; >>>>> }; >>>>> >>>>> ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? >>>>> >>>>> In /proc/interrupts there's no rtc assigned to an interrupt 53. >>>> >>>> There is code in the driver to request this interrupt. Do you see an >>>> error message like: >>>> >>>> interrupt not available. >>>> >>> >>> No. >>> >>>>> Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 >>>>> entries works >>>>> well and setting the date/time via "hwclock --systohc" does its job >>>>> too. So >>>>> I2C and the rtc_s35390a driver seem to work so far. >>>> >>>> Now i'm confused. I don't see any mention of s35390a for any TS >>>> devices. Some kirkwood machines do make use of an external RTC, not >>>> the built in. But not this machine, as far as i know. >>> >>> I snipped some dmesg log pointing to the machine & clock/rtc: >>> >>> [ 0.000000] Booting Linux on physical CPU 0x0 >>> [ 0.000000] Linux version 4.19.0-5-marvell >>> (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) >>> #1 Debian 4.19.37-5 (2019-06-19) >>> [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), >>> cr=0005397f >>> [ 0.000000] CPU: VIVT data cache, VIVT instruction cache >>> [ 0.000000] OF: fdt: Machine model: QNAP TS219 family >>> >>> (..) >>> >>> [ 0.000000] clocksource: orion_clocksource: mask: 0xffffffff >>> max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns >>> [ 0.000006] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps >>> every 10737418237ns >>> [ 0.000030] Switching to timer-based delay loop, resolution 5ns >>> [ 0.000099] Calibrating delay loop (skipped), value calculated >>> using timer frequency.. 400.00 BogoMIPS (lpj=800000) >>> [ 0.000117] pid_max: default: 32768 minimum: 301 >>> [ 0.000329] Security Framework initialized >>> [ 0.000344] Yama: disabled by default; enable with sysctl >>> kernel.yama.* >>> [ 0.000427] AppArmor: AppArmor initialized >>> [ 0.000528] Mount-cache hash table entries: 1024 (order: 0, 4096 >>> bytes) >>> [ 0.000544] Mountpoint-cache hash table entries: 1024 (order: 0, >>> 4096 bytes) >>> [ 0.001288] CPU: Testing write buffer coherency: ok >>> [ 0.002027] Setting up static identity map for 0x8200 - 0x823c >>> [ 0.002207] mvebu-soc-id: MVEBU SoC ID=0x6282, Rev=0x0 >>> [ 0.003536] devtmpfs: initialized >>> [ 0.006261] VFP support v0.3: not present >>> [ 0.006378] clocksource: jiffies: mask: 0xffffffff max_cycles: >>> 0xffffffff, max_idle_ns: 7645041785100000 ns >>> >>> (..) >>> >>> [ 1.198026] hctosys: unable to open rtc device (rtc0) >>> [ 1.205324] Freeing unused kernel memory: 312K >>> [ 1.209804] This architecture does not have kernel memory protection. >>> [ 1.216276] Run /init as init process >>> [ 1.299536] random: fast init done >>> [ 1.581741] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a >>> as rtc0 >>> >>> (..) >>> >>> [ 11.395565] rtc-mv f1010300.rtc: internal RTC not ticking >>> >>> I got the information from Martin Michlmayr's Quap Debian pages: >>> http://www.cyrius.com/debian/kirkwood/qnap/ts-219/status/ >>> http://www.cyrius.com/debian/kirkwood/qnap/ts-119/status/ >>> >>> RTC: Supported in the kernel by the rtc-s35390a module >>> >>> Thanks for your help! >>> >>> Best, >>> Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 18:30 ` Oliver Hartkopp 2019-07-23 19:05 ` Oliver Hartkopp @ 2019-07-23 22:15 ` Andrew Lunn 1 sibling, 0 replies; 16+ messages in thread From: Andrew Lunn @ 2019-07-23 22:15 UTC (permalink / raw) To: Oliver Hartkopp; +Cc: tbm, linux-arm-kernel On Tue, Jul 23, 2019 at 08:30:45PM +0200, Oliver Hartkopp wrote: > Sorry for answering myself again .. > > After installing the 4.9.0-4-marvell kernel (from old stable Stretch) on my > Debian Buster system it works like before: > > [ 1.101214] mousedev: PS/2 mouse device common for all mice > [ 2.123021] rtc-mv f1010300.rtc: internal RTC not ticking > [ 2.128592] i2c /dev entries driver > [ 2.133933] random: fast init done > [ 2.137746] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0 > [ 2.145186] ledtrig-cpu: registered to indicate activity on CPUs > [ 2.151518] NET: Registered protocol family 17 > [ 2.156398] registered taskstats version 1 > [ 2.160561] zswap: loaded using pool lzo/zbud > [ 2.165913] rtc-s35390a 0-0030: setting system clock to 2019-07-23 > 18:16:18 UTC (1563905778) > [ 2.175514] Freeing unused kernel memory: 296K So your system has two RTC drivers loading. First rtc-mv tries to load, but it finds the RTC is not ticking. This often happens with Kirkwood. Some vendors decided not to use the internal RTC. But the default device tree has it enabled, so the driver loads. When it pokes the hardware it discovers the clock is stopped and so the driver fails the problem. Later the i2c RTC loads, which does work. So one step is to change the DT to disable the internal RTC. You can add: rtc@10300 { status = "disabled"; }; Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 17:56 ` Oliver Hartkopp 2019-07-23 18:30 ` Oliver Hartkopp @ 2019-07-23 21:07 ` Russell King - ARM Linux admin 1 sibling, 0 replies; 16+ messages in thread From: Russell King - ARM Linux admin @ 2019-07-23 21:07 UTC (permalink / raw) To: Oliver Hartkopp; +Cc: Andrew Lunn, tbm, linux-arm-kernel On Tue, Jul 23, 2019 at 07:56:46PM +0200, Oliver Hartkopp wrote: > I just found an older log booting a Linux 4.9 where it was ok: > > Jan 6 20:57:03 sam kernel: [ 0.000000] Booting Linux on physical CPU 0x0 > Jan 6 20:57:03 sam kernel: [ 0.000000] Linux version 4.9.0-4-marvell > (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian > 6.3.0-18) ) #1 Debian 4.9.51-1 (2017-09-28) > Jan 6 20:57:03 sam kernel: [ 0.000000] CPU: Feroceon 88FR131 [56251311] > revision 1 (ARMv5TE), cr=0005397f > Jan 6 20:57:03 sam kernel: [ 0.000000] CPU: VIVT data cache, VIVT > instruction cache > Jan 6 20:57:03 sam kernel: [ 0.000000] OF: fdt:Machine model: QNAP TS219 > family > > (..) > > Jan 6 20:57:03 sam kernel: [ 1.052175] mousedev: PS/2 mouse device > common for all mice > Jan 6 20:57:03 sam kernel: [ 2.090654] rtc-mv f1010300.rtc: internal RTC > not ticking > Jan 6 20:57:03 sam kernel: [ 2.096219] i2c /dev entries driver > Jan 6 20:57:03 sam kernel: [ 2.101859] rtc-s35390a 0-0030: rtc core: > registered rtc-s35390a as rtc0 > Jan 6 20:57:03 sam kernel: [ 2.109296] ledtrig-cpu: registered to > indicate activity on CPUs > Jan 6 20:57:03 sam kernel: [ 2.115640] NET: Registered protocol family > 17 > Jan 6 20:57:03 sam kernel: [ 2.120536] registered taskstats version 1 > Jan 6 20:57:03 sam kernel: [ 2.124695] zswap: loaded using pool lzo/zbud > Jan 6 20:57:03 sam kernel: [ 2.129852] random: fast init done > Jan 6 20:57:03 sam kernel: [ 2.133441] rtc-s35390a 0-0030: setting > system clock to 2018-01-06 19:56:53 UTC (1515268613) > Jan 6 20:57:03 sam kernel: [ 2.143039] Freeing unused kernel memory: > 296K > > Just wondering whether this a kernel problem or a systemd thing. > > At least the rtc-s35390a module is loaded before is is accessed. This looks like it was built-in to this kernel. The other kernel log shows that it was loaded later. > > Regards, > Oliver > > > Hi Andrew, > > > > On 23.07.19 18:12, Andrew Lunn wrote: > > > On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: > > > > > > I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. > > > > > > Hi Oliver > > > > > > Did the same test work with older Debians? > > > > > > > I'm not really sure when it happened, as I was using the 'testing' > > release which now lead to Buster. I have no clear point where to look. > > Just detected some boot delay and looked into the sysctl log wich moved > > the clock forward based on fact, that the installed binaries where > > younger than the system clock. %-( > > > > > > I wonder whether the problem comes from a missing interrupt assignment > > > > > > > > rtc: rtc@10300 { > > > > compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; > > > > reg = <0x10300 0x20>; > > > > interrupts = <53>; <- HERE!?! > > > > clocks = <&gate_clk 7>; > > > > }; > > > > > > > > ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? > > > > > > > > In /proc/interrupts there's no rtc assigned to an interrupt 53. > > > > > > There is code in the driver to request this interrupt. Do you see an > > > error message like: > > > > > > interrupt not available. > > > > > > > No. > > > > > > Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 > > > > entries works > > > > well and setting the date/time via "hwclock --systohc" does its > > > > job too. So > > > > I2C and the rtc_s35390a driver seem to work so far. > > > > > > Now i'm confused. I don't see any mention of s35390a for any TS > > > devices. Some kirkwood machines do make use of an external RTC, not > > > the built in. But not this machine, as far as i know. > > > > I snipped some dmesg log pointing to the machine & clock/rtc: > > > > [ 0.000000] Booting Linux on physical CPU 0x0 > > [ 0.000000] Linux version 4.19.0-5-marvell > > (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 > > Debian 4.19.37-5 (2019-06-19) > > [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), > > cr=0005397f > > [ 0.000000] CPU: VIVT data cache, VIVT instruction cache > > [ 0.000000] OF: fdt: Machine model: QNAP TS219 family > > > > (..) > > > > [ 0.000000] clocksource: orion_clocksource: mask: 0xffffffff > > max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns > > [ 0.000006] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps > > every 10737418237ns > > [ 0.000030] Switching to timer-based delay loop, resolution 5ns > > [ 0.000099] Calibrating delay loop (skipped), value calculated using > > timer frequency.. 400.00 BogoMIPS (lpj=800000) > > [ 0.000117] pid_max: default: 32768 minimum: 301 > > [ 0.000329] Security Framework initialized > > [ 0.000344] Yama: disabled by default; enable with sysctl kernel.yama.* > > [ 0.000427] AppArmor: AppArmor initialized > > [ 0.000528] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) > > [ 0.000544] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 > > bytes) > > [ 0.001288] CPU: Testing write buffer coherency: ok > > [ 0.002027] Setting up static identity map for 0x8200 - 0x823c > > [ 0.002207] mvebu-soc-id: MVEBU SoC ID=0x6282, Rev=0x0 > > [ 0.003536] devtmpfs: initialized > > [ 0.006261] VFP support v0.3: not present > > [ 0.006378] clocksource: jiffies: mask: 0xffffffff max_cycles: > > 0xffffffff, max_idle_ns: 7645041785100000 ns > > > > (..) > > > > [ 1.198026] hctosys: unable to open rtc device (rtc0) > > [ 1.205324] Freeing unused kernel memory: 312K > > [ 1.209804] This architecture does not have kernel memory protection. > > [ 1.216276] Run /init as init process > > [ 1.299536] random: fast init done > > [ 1.581741] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0 > > > > (..) > > > > [ 11.395565] rtc-mv f1010300.rtc: internal RTC not ticking > > > > I got the information from Martin Michlmayr's Quap Debian pages: > > http://www.cyrius.com/debian/kirkwood/qnap/ts-219/status/ > > http://www.cyrius.com/debian/kirkwood/qnap/ts-119/status/ > > > > RTC: Supported in the kernel by the rtc-s35390a module > > > > Thanks for your help! > > > > Best, > > Oliver > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 15:30 TS-219 RTC issue with Debian Buster Oliver Hartkopp @ 2019-07-23 19:06 ` Uwe Kleine-König 2019-07-23 19:06 ` Uwe Kleine-König 1 sibling, 0 replies; 16+ messages in thread From: Uwe Kleine-König @ 2019-07-23 19:06 UTC (permalink / raw) To: Oliver Hartkopp Cc: linux-arm-kernel, Andrew Lunn, tbm, Alessandro Zummo, Alexandre Belloni, linux-rtc Hello Oliver, I added the RTC maintainers and list to Cc. On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: > I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. > > They use dtbs/4.19.0-5-marvell/./kirkwood-ts219-6282.dtb > > Unfortunately the RTC doesn't seem to work. > > root@xxxxx:~# hwclock -v --test > hwclock from util-linux 2.33.1 > System Time: 1563296223.425648 > Trying to open: /dev/rtc0 > Using the rtc interface to the clock. > Last drift adjustment done at 1563291472 seconds after 1969 > Last calibration done at 1563291472 seconds after 1969 > Hardware clock is on UTC time > Assuming hardware clock is kept in UTC time. > Waiting for clock tick... > hwclock: select() to /dev/rtc0 to wait for clock tick timed out > ...synchronization failed > Test mode: nothing was changed. > With strace the clock tick problem looks like this: > > write(1, "Waiting for clock tick...\n", 26Waiting for clock tick... > ) = 26 > ioctl(4, RTC_UIE_ON) = 0 > _newselect(5, [4], NULL, NULL, {tv_sec=10, tv_usec=0}) = 0 (Timeout) > write(2, "hwclock: ", 9hwclock: ) = 9 > write(2, "select() to /dev/rtc0 to wait fo"..., 54select() to /dev/rtc0 to > wait for clock tick timed out) = 54 > write(2, "\n", 1) = 1 > ioctl(4, PHN_NOT_OH or RTC_UIE_OFF) = 0 Maybe rtc-mv should set uie_unsupported if no irq is aquired? > It looks the same with > > # hwclock --hctosys > hwclock: select() to /dev/rtc0 to wait for clock tick timed out hwclock (from util-linux) is being stupid here. The tradtional RTC on the x86 platform has a resolution of 1s only and if you set it the next increment is 1 second after the last increment instead of 1 second after the new time was set. So hwclock waits for an update event and then sets the new time (in some cases to a tad later than requested) to ensure the PC clock is off by less than half a second. For most (if not all) other RTCs this is wrong and still worse if the RTC in question doesn't support UIE. > I wonder whether the problem comes from a missing interrupt assignment > > rtc: rtc@10300 { > compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; > reg = <0x10300 0x20>; > interrupts = <53>; <- HERE!?! > clocks = <&gate_clk 7>; > }; > > ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? > > In /proc/interrupts there's no rtc assigned to an interrupt 53. What is the output of dmesg | grep 10300 ? > Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries works > well and setting the date/time via "hwclock --systohc" does its job too. So > I2C and the rtc_s35390a driver seem to work so far. You're not using the s35390a driver, do you? > Any ideas why hwclock fails to work properly? Try if busybox hwclock works better for you. At least this one doesn't have this strange PC quirk. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster @ 2019-07-23 19:06 ` Uwe Kleine-König 0 siblings, 0 replies; 16+ messages in thread From: Uwe Kleine-König @ 2019-07-23 19:06 UTC (permalink / raw) To: Oliver Hartkopp Cc: linux-rtc, Andrew Lunn, Alexandre Belloni, Alessandro Zummo, tbm, linux-arm-kernel Hello Oliver, I added the RTC maintainers and list to Cc. On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: > I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. > > They use dtbs/4.19.0-5-marvell/./kirkwood-ts219-6282.dtb > > Unfortunately the RTC doesn't seem to work. > > root@xxxxx:~# hwclock -v --test > hwclock from util-linux 2.33.1 > System Time: 1563296223.425648 > Trying to open: /dev/rtc0 > Using the rtc interface to the clock. > Last drift adjustment done at 1563291472 seconds after 1969 > Last calibration done at 1563291472 seconds after 1969 > Hardware clock is on UTC time > Assuming hardware clock is kept in UTC time. > Waiting for clock tick... > hwclock: select() to /dev/rtc0 to wait for clock tick timed out > ...synchronization failed > Test mode: nothing was changed. > With strace the clock tick problem looks like this: > > write(1, "Waiting for clock tick...\n", 26Waiting for clock tick... > ) = 26 > ioctl(4, RTC_UIE_ON) = 0 > _newselect(5, [4], NULL, NULL, {tv_sec=10, tv_usec=0}) = 0 (Timeout) > write(2, "hwclock: ", 9hwclock: ) = 9 > write(2, "select() to /dev/rtc0 to wait fo"..., 54select() to /dev/rtc0 to > wait for clock tick timed out) = 54 > write(2, "\n", 1) = 1 > ioctl(4, PHN_NOT_OH or RTC_UIE_OFF) = 0 Maybe rtc-mv should set uie_unsupported if no irq is aquired? > It looks the same with > > # hwclock --hctosys > hwclock: select() to /dev/rtc0 to wait for clock tick timed out hwclock (from util-linux) is being stupid here. The tradtional RTC on the x86 platform has a resolution of 1s only and if you set it the next increment is 1 second after the last increment instead of 1 second after the new time was set. So hwclock waits for an update event and then sets the new time (in some cases to a tad later than requested) to ensure the PC clock is off by less than half a second. For most (if not all) other RTCs this is wrong and still worse if the RTC in question doesn't support UIE. > I wonder whether the problem comes from a missing interrupt assignment > > rtc: rtc@10300 { > compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; > reg = <0x10300 0x20>; > interrupts = <53>; <- HERE!?! > clocks = <&gate_clk 7>; > }; > > ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? > > In /proc/interrupts there's no rtc assigned to an interrupt 53. What is the output of dmesg | grep 10300 ? > Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries works > well and setting the date/time via "hwclock --systohc" does its job too. So > I2C and the rtc_s35390a driver seem to work so far. You're not using the s35390a driver, do you? > Any ideas why hwclock fails to work properly? Try if busybox hwclock works better for you. At least this one doesn't have this strange PC quirk. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 19:06 ` Uwe Kleine-König @ 2019-07-23 19:21 ` Oliver Hartkopp -1 siblings, 0 replies; 16+ messages in thread From: Oliver Hartkopp @ 2019-07-23 19:21 UTC (permalink / raw) To: Uwe Kleine-König Cc: linux-arm-kernel, Andrew Lunn, tbm, Alessandro Zummo, Alexandre Belloni, linux-rtc Hello Uwe, nice to read from you again :-) I think I already solved the problem, see here: https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2 Will file a Debian bug for it ... Many thanks, Oliver On 23.07.19 21:06, Uwe Kleine-König wrote: > Hello Oliver, > > I added the RTC maintainers and list to Cc. > > On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: >> I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. >> >> They use dtbs/4.19.0-5-marvell/./kirkwood-ts219-6282.dtb >> >> Unfortunately the RTC doesn't seem to work. >> >> root@xxxxx:~# hwclock -v --test >> hwclock from util-linux 2.33.1 >> System Time: 1563296223.425648 >> Trying to open: /dev/rtc0 >> Using the rtc interface to the clock. >> Last drift adjustment done at 1563291472 seconds after 1969 >> Last calibration done at 1563291472 seconds after 1969 >> Hardware clock is on UTC time >> Assuming hardware clock is kept in UTC time. >> Waiting for clock tick... >> hwclock: select() to /dev/rtc0 to wait for clock tick timed out >> ...synchronization failed >> Test mode: nothing was changed. >> With strace the clock tick problem looks like this: >> >> write(1, "Waiting for clock tick...\n", 26Waiting for clock tick... >> ) = 26 >> ioctl(4, RTC_UIE_ON) = 0 >> _newselect(5, [4], NULL, NULL, {tv_sec=10, tv_usec=0}) = 0 (Timeout) >> write(2, "hwclock: ", 9hwclock: ) = 9 >> write(2, "select() to /dev/rtc0 to wait fo"..., 54select() to /dev/rtc0 to >> wait for clock tick timed out) = 54 >> write(2, "\n", 1) = 1 >> ioctl(4, PHN_NOT_OH or RTC_UIE_OFF) = 0 > > Maybe rtc-mv should set uie_unsupported if no irq is aquired? > >> It looks the same with >> >> # hwclock --hctosys >> hwclock: select() to /dev/rtc0 to wait for clock tick timed out > > hwclock (from util-linux) is being stupid here. The tradtional RTC on > the x86 platform has a resolution of 1s only and if you set it the next > increment is 1 second after the last increment instead of 1 second after > the new time was set. So hwclock waits for an update event and then sets > the new time (in some cases to a tad later than requested) to ensure the > PC clock is off by less than half a second. For most (if not all) other > RTCs this is wrong and still worse if the RTC in question doesn't > support UIE. > >> I wonder whether the problem comes from a missing interrupt assignment >> >> rtc: rtc@10300 { >> compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; >> reg = <0x10300 0x20>; >> interrupts = <53>; <- HERE!?! >> clocks = <&gate_clk 7>; >> }; >> >> ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? >> >> In /proc/interrupts there's no rtc assigned to an interrupt 53. > > What is the output of dmesg | grep 10300 ? > >> Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries works >> well and setting the date/time via "hwclock --systohc" does its job too. So >> I2C and the rtc_s35390a driver seem to work so far. > > You're not using the s35390a driver, do you? > >> Any ideas why hwclock fails to work properly? > > Try if > > busybox hwclock > > works better for you. At least this one doesn't have this strange PC > quirk. > > Best regards > Uwe > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster @ 2019-07-23 19:21 ` Oliver Hartkopp 0 siblings, 0 replies; 16+ messages in thread From: Oliver Hartkopp @ 2019-07-23 19:21 UTC (permalink / raw) To: Uwe Kleine-König Cc: linux-rtc, Andrew Lunn, Alexandre Belloni, Alessandro Zummo, tbm, linux-arm-kernel Hello Uwe, nice to read from you again :-) I think I already solved the problem, see here: https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2 Will file a Debian bug for it ... Many thanks, Oliver On 23.07.19 21:06, Uwe Kleine-König wrote: > Hello Oliver, > > I added the RTC maintainers and list to Cc. > > On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: >> I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. >> >> They use dtbs/4.19.0-5-marvell/./kirkwood-ts219-6282.dtb >> >> Unfortunately the RTC doesn't seem to work. >> >> root@xxxxx:~# hwclock -v --test >> hwclock from util-linux 2.33.1 >> System Time: 1563296223.425648 >> Trying to open: /dev/rtc0 >> Using the rtc interface to the clock. >> Last drift adjustment done at 1563291472 seconds after 1969 >> Last calibration done at 1563291472 seconds after 1969 >> Hardware clock is on UTC time >> Assuming hardware clock is kept in UTC time. >> Waiting for clock tick... >> hwclock: select() to /dev/rtc0 to wait for clock tick timed out >> ...synchronization failed >> Test mode: nothing was changed. >> With strace the clock tick problem looks like this: >> >> write(1, "Waiting for clock tick...\n", 26Waiting for clock tick... >> ) = 26 >> ioctl(4, RTC_UIE_ON) = 0 >> _newselect(5, [4], NULL, NULL, {tv_sec=10, tv_usec=0}) = 0 (Timeout) >> write(2, "hwclock: ", 9hwclock: ) = 9 >> write(2, "select() to /dev/rtc0 to wait fo"..., 54select() to /dev/rtc0 to >> wait for clock tick timed out) = 54 >> write(2, "\n", 1) = 1 >> ioctl(4, PHN_NOT_OH or RTC_UIE_OFF) = 0 > > Maybe rtc-mv should set uie_unsupported if no irq is aquired? > >> It looks the same with >> >> # hwclock --hctosys >> hwclock: select() to /dev/rtc0 to wait for clock tick timed out > > hwclock (from util-linux) is being stupid here. The tradtional RTC on > the x86 platform has a resolution of 1s only and if you set it the next > increment is 1 second after the last increment instead of 1 second after > the new time was set. So hwclock waits for an update event and then sets > the new time (in some cases to a tad later than requested) to ensure the > PC clock is off by less than half a second. For most (if not all) other > RTCs this is wrong and still worse if the RTC in question doesn't > support UIE. > >> I wonder whether the problem comes from a missing interrupt assignment >> >> rtc: rtc@10300 { >> compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; >> reg = <0x10300 0x20>; >> interrupts = <53>; <- HERE!?! >> clocks = <&gate_clk 7>; >> }; >> >> ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? >> >> In /proc/interrupts there's no rtc assigned to an interrupt 53. > > What is the output of dmesg | grep 10300 ? > >> Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries works >> well and setting the date/time via "hwclock --systohc" does its job too. So >> I2C and the rtc_s35390a driver seem to work so far. > > You're not using the s35390a driver, do you? > >> Any ideas why hwclock fails to work properly? > > Try if > > busybox hwclock > > works better for you. At least this one doesn't have this strange PC > quirk. > > Best regards > Uwe > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 19:21 ` Oliver Hartkopp @ 2019-07-23 19:34 ` Uwe Kleine-König -1 siblings, 0 replies; 16+ messages in thread From: Uwe Kleine-König @ 2019-07-23 19:34 UTC (permalink / raw) To: Oliver Hartkopp Cc: linux-arm-kernel, Andrew Lunn, tbm, Alessandro Zummo, Alexandre Belloni, linux-rtc Hello Oliver, On Tue, Jul 23, 2019 at 09:21:06PM +0200, Oliver Hartkopp wrote: > I think I already solved the problem, see here: > https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2 IMHO the right fix is teach hwclock to handle your rtc correctly. Changing the driver from =m to =y is only a workaround. Maybe also using the time stuff from systemd instead of hwclock will help^Wwork around your problem (not sure though). Also I wonder why the ioctl to enable UIE doesn't fail if the driver set .uie_unsupported (but I didn't look closely). > Will file a Debian bug for it ... Not sure this will have success. These were switched from =y to =m because the kernel images got to big. (https://salsa.debian.org/kernel-team/linux/commit/c55043a43eaacb9f876dabd71273b084cb024441) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster @ 2019-07-23 19:34 ` Uwe Kleine-König 0 siblings, 0 replies; 16+ messages in thread From: Uwe Kleine-König @ 2019-07-23 19:34 UTC (permalink / raw) To: Oliver Hartkopp Cc: linux-rtc, Andrew Lunn, Alexandre Belloni, Alessandro Zummo, tbm, linux-arm-kernel Hello Oliver, On Tue, Jul 23, 2019 at 09:21:06PM +0200, Oliver Hartkopp wrote: > I think I already solved the problem, see here: > https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2 IMHO the right fix is teach hwclock to handle your rtc correctly. Changing the driver from =m to =y is only a workaround. Maybe also using the time stuff from systemd instead of hwclock will help^Wwork around your problem (not sure though). Also I wonder why the ioctl to enable UIE doesn't fail if the driver set .uie_unsupported (but I didn't look closely). > Will file a Debian bug for it ... Not sure this will have success. These were switched from =y to =m because the kernel images got to big. (https://salsa.debian.org/kernel-team/linux/commit/c55043a43eaacb9f876dabd71273b084cb024441) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 19:34 ` Uwe Kleine-König @ 2019-07-23 20:07 ` Oliver Hartkopp -1 siblings, 0 replies; 16+ messages in thread From: Oliver Hartkopp @ 2019-07-23 20:07 UTC (permalink / raw) To: Uwe Kleine-König Cc: linux-arm-kernel, Andrew Lunn, tbm, Alessandro Zummo, Alexandre Belloni, linux-rtc Hello Uwe, On 23.07.19 21:34, Uwe Kleine-König wrote: > On Tue, Jul 23, 2019 at 09:21:06PM +0200, Oliver Hartkopp wrote: >> I think I already solved the problem, see here: >> https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2 > > IMHO the right fix is teach hwclock to handle your rtc correctly. > Changing the driver from =m to =y is only a workaround. Agreed. > Maybe also using the time stuff from systemd instead of hwclock will > help^Wwork around your problem (not sure though). > > Also I wonder why the ioctl to enable UIE doesn't fail if the driver set > .uie_unsupported (but I didn't look closely). Right. When executing the ioctl(4, RTC_UIE_ON) syscall it just get's stuck and the select() timeout captures the call after 10 seconds. I would have expected that ioctl(4, RTC_UIE_ON) returns with some -EINVAL or -ENOTSUPP value. I'm not sure if hwclock needs the trigger for precision reasons: https://github.com/karelzak/util-linux/blob/master/sys-utils/hwclock.c#L276 ... or if this can be omitted. >> Will file a Debian bug for it ... > > Not sure this will have success. These were switched from =y to =m > because the kernel images got to big. > (https://salsa.debian.org/kernel-team/linux/commit/c55043a43eaacb9f876dabd71273b084cb024441) Too late ;-) I will just wait for the answer. Best regards, Oliver ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: TS-219 RTC issue with Debian Buster @ 2019-07-23 20:07 ` Oliver Hartkopp 0 siblings, 0 replies; 16+ messages in thread From: Oliver Hartkopp @ 2019-07-23 20:07 UTC (permalink / raw) To: Uwe Kleine-König Cc: linux-rtc, Andrew Lunn, Alexandre Belloni, Alessandro Zummo, tbm, linux-arm-kernel Hello Uwe, On 23.07.19 21:34, Uwe Kleine-König wrote: > On Tue, Jul 23, 2019 at 09:21:06PM +0200, Oliver Hartkopp wrote: >> I think I already solved the problem, see here: >> https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2 > > IMHO the right fix is teach hwclock to handle your rtc correctly. > Changing the driver from =m to =y is only a workaround. Agreed. > Maybe also using the time stuff from systemd instead of hwclock will > help^Wwork around your problem (not sure though). > > Also I wonder why the ioctl to enable UIE doesn't fail if the driver set > .uie_unsupported (but I didn't look closely). Right. When executing the ioctl(4, RTC_UIE_ON) syscall it just get's stuck and the select() timeout captures the call after 10 seconds. I would have expected that ioctl(4, RTC_UIE_ON) returns with some -EINVAL or -ENOTSUPP value. I'm not sure if hwclock needs the trigger for precision reasons: https://github.com/karelzak/util-linux/blob/master/sys-utils/hwclock.c#L276 ... or if this can be omitted. >> Will file a Debian bug for it ... > > Not sure this will have success. These were switched from =y to =m > because the kernel images got to big. > (https://salsa.debian.org/kernel-team/linux/commit/c55043a43eaacb9f876dabd71273b084cb024441) Too late ;-) I will just wait for the answer. Best regards, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-07-23 22:15 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-23 15:30 TS-219 RTC issue with Debian Buster Oliver Hartkopp 2019-07-23 16:12 ` Andrew Lunn 2019-07-23 17:31 ` Oliver Hartkopp 2019-07-23 17:56 ` Oliver Hartkopp 2019-07-23 18:30 ` Oliver Hartkopp 2019-07-23 19:05 ` Oliver Hartkopp 2019-07-23 22:15 ` Andrew Lunn 2019-07-23 21:07 ` Russell King - ARM Linux admin 2019-07-23 19:06 ` Uwe Kleine-König 2019-07-23 19:06 ` Uwe Kleine-König 2019-07-23 19:21 ` Oliver Hartkopp 2019-07-23 19:21 ` Oliver Hartkopp 2019-07-23 19:34 ` Uwe Kleine-König 2019-07-23 19:34 ` Uwe Kleine-König 2019-07-23 20:07 ` Oliver Hartkopp 2019-07-23 20:07 ` Oliver Hartkopp
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.