All of lore.kernel.org
 help / color / mirror / Atom feed
* 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 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
* 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 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
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.