Time is lagging substantially on Netgear ReadyNAS RN102 and RN104
Posted by tme
|
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 July 23, 2024 02:17PM |
Admin Registered: 13 years ago Posts: 19,107 |
Hi Trond,
The correct addresses to dump SAR.
On Mirabox
At 0xd0018230, Bit 20 == 1 indicates 200Mhz.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/23/2024 02:19PM by bodhi.
The correct addresses to dump SAR.
On Mirabox
Marvell>> md.l 0xd0018230 1 d0018230: 0012b397 .... Marvell>> md.l 0xd0018234 1 d0018234: 00000000 ....
At 0xd0018230, Bit 20 == 1 indicates 200Mhz.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/23/2024 02:19PM by bodhi.
|
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 July 23, 2024 03:35PM |
Registered: 7 years ago Posts: 189 |
|
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 July 23, 2024 06:57PM |
Admin Registered: 13 years ago Posts: 19,107 |
Hi Trond,
> On RN102 (warm start):
>
Ok. So we can see BIT 20 was set to 200 Mhz (001 2b395), same as the Mirabox.
I will post a test kernel so we can see in Linux if the SAR register content is the same as in u-boot. The Mirabox shows the same value in u-boot.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> On RN102 (warm start):
>
> Marvell>> md.l 0xd0018230 1 > d0018230: 0012b395 .... > Marvell>> md.l 0xd0018234 1 > d0018234: 00000000 .... >>
Ok. So we can see BIT 20 was set to 200 Mhz (001 2b395), same as the Mirabox.
I will post a test kernel so we can see in Linux if the SAR register content is the same as in u-boot. The Mirabox shows the same value in u-boot.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 July 23, 2024 07:02PM |
Admin Registered: 13 years ago Posts: 19,107 |
Here is the test kernel linux-6.9.6-mvebu-370xp-tld-3.x. This kernel is the same as the released kernel linux-6.9.6-mvebu-370xp-tld-2, but with some more debug loggings during boot.
Download at Dropbox
linux-6.9.6-mvebu-370xp-tld-3.x-bodhi.tar.bz2
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Download at Dropbox
linux-6.9.6-mvebu-370xp-tld-3.x-bodhi.tar.bz2
md5sum linux-6.9.6-mvebu-370xp-tld-3.x-bodhi.tar.bz2 d680f87fa4aab42522614fc5943b641e linux-6.9.6-mvebu-370xp-tld-3.x-bodhi.tar.bz2 sha256sum linux-6.9.6-mvebu-370xp-tld-3.x-bodhi.tar.bz2 a8ae012e9fca7351cb9c9b42b2b4ca1ec6f65c77802f597266fa49b4ce1186e4 linux-6.9.6-mvebu-370xp-tld-3.x-bodhi.tar.bz2
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 July 23, 2024 09:29PM |
Registered: 7 years ago Posts: 189 |
Thanks, bodhi!
Installed on RN102:
Full 'dmesg' output attached.
Regards,
Trond Melen
Installed on RN102:
$ dmesg | grep armada [ 0.000000] armada-370: SAR Reg Addr = 0xe080f230 SAR Reg = 0x12b395 TCLK = 200 MHz [ 0.000000] armada_370_timer_init: timer_clk: 18749237 [ 0.000000] armada_370_xp_timer_common_init: timer_clk: 18749237 [ 0.007890] clocksource: armada_370_xp_clocksource: scale: 1 ns, freq: 18749237 [ 0.015204] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 101938038664 ns [ 1.184366] clocksource: Switched to clocksource armada_370_xp_clocksource [ 1.932340] armada-370-pinctrl d0018000.pin-ctrl: registered pinctrl driver [ 22.714873] armada-370-pinctrl d0018000.pin-ctrl: unsupported function audio on pin mpp51
Full 'dmesg' output attached.
Regards,
Trond Melen
|
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 July 23, 2024 10:01PM |
Admin Registered: 13 years ago Posts: 19,107 |
Hi Trond,
Thanks! so that theory about TCLK is proven not to be.
BTW, I looked at the GPL code
The reason for the double print for mtdparts and other args "reason=normal bdtype=rn102" is because: before booting, this u-boot always append mtdparts and those 2 arguments to the current bootargs env value.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Thanks! so that theory about TCLK is proven not to be.
BTW, I looked at the GPL code
Quote
[ 0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=pxa3xx_nand-0:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs) earlyprintk=serial mtdparts=pxa3xx_nand-0:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs) reason=normal bdtype=rn102
The reason for the double print for mtdparts and other args "reason=normal bdtype=rn102" is because: before booting, this u-boot always append mtdparts and those 2 arguments to the current bootargs env value.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
