Thanks, bodhi! 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: armaby tme - Debian
Hi bodhi, On RN102 (warm start): Marvell>> md.l 0xd0018230 1 d0018230: 0012b395 .... Marvell>> md.l 0xd0018234 1 d0018234: 00000000 .... Regards, Trond Melenby tme - Debian
Hi bodhi, Quote Please cold start (after shutdown for about 30 minutes) your RN102 or RN104. Interrupt u-boot at count down and dump SAR register RN102 warm start: Marvell>> md.l 0x18230 1 00018230: e12fff1e ../. Marvell>> md.l 0x18234 1 00018234: e3a00000 .... RN102 cold start: Marvell>> md.l 0x18230 1 00018230: e12fff1e ../. Marvell>> md.l 0x182by tme - Debian
Hi bodhi, Quote Please cold start your RN102 or RN104. Interrupt u-boot at count down and dump SAR register I'm currently not co-located with my TTL-to-USB adapter. I'll report when we are reunited. Regards, Trond Melenby tme - Debian
Hi bodhi, Quotebodhi Wish we have GPL source for the RN102 u-boot so we can see what it does during boot. I found a file named "ReadyNASOS_V6.6.0_WW_src.zip" dated October 2020 on my file server, but I don't recall from where I got it. Within it there is a top level directory "u-boot-2011.12-armada370" containing the GPL source code for a version of U-Boot with builby tme - Debian
Hi bodhi, Marvell>> SatR read cpufreq cpufreq = 255 Marvell>> SatR read fabfreq fabfreq = 255 Marvell>> SatR read freq Current freq mode is invalid! Marvell>> SatR read bootsrc 3(255) = opt' = user manual option (opt) Marvell>> SatR read pex pex = 65535 Marvell>> These parameters all seem to be uninitialized, so probably they are ignby tme - Debian
Hi bodhi, From RN102 U-Boot: BootROM 1.08 Booting from NAND flash General initialization - Version: 1.0.0 High speed PHY - Version: 2.1.4 (COM-PHY-V20) Update PEX Device ID 0x6710 High speed PHY - Ended Successfully 0000 DDR3 Training Sequence - Ver 5.7.1 DDR3 Training Sequence - Run without PBS. DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verificatby tme - Debian
Hi bodhi, octave:1> 55/60 ans = 0.9167 octave:2> 18749237/18699646 ans = 1.0027 octave:3> (1-55/60)/(1-18749237/18699646) ans = -31.423 The observed lagging is 31 times larger than the difference in reported frequency, so there must be more to it than just the clock frequency. Regards, Trond Melenby tme - Debian
Hi bodhi, I agree. 114.8 s wrap time (Mirabox) is correct and 114.5 s (RN102) is wrong. So then it's wrong already after 6 us. I successfully installed Linux kernel version 6.9.6 on one of my RN102 boxes. It seems to work fine: $ uname -a Linux rn102 6.9.6-mvebu-370xp-tld-2 #2 PREEMPT Wed Jul 3 17:10:27 PDT 2024 armv7l GNU/Linux The relevant 'dmesg' lines are: $ dmeby tme - Debian
Hi Jungle, I just checked my second RN102. Plenty of Ethernet RX buffer overrun errors on this one, so this issue is not limited to RN104. The box has been up for about 10 weeks. The Linux kernel version is 6.7.5. This issue may have been introduced between Linux version 6.5.7 (24 Oct 2023) and 6.7.5 (13 Mar 2024), or maybe one just have to load the box sufficiently and wait long enough forby tme - Debian
Hi Jungle, QuoteI also want to be able to use the LCD or at least turn off the backlight. Did you succeed? /usr/bin/printf '\x1b[L-' > /dev/lcd should do the trick. My most relevant post on this topic is https://forum.doozan.com/read.php?9,133864,133997#msg-133997 and the next one. Regards, Trond Melenby tme - Debian
Hi Jungle, Still no Ethernet RX buffer overruns after upgrading the Linux kernel from 6.4.11 (22 Aug 2023) to 6.5.7 (24 Oct 2023): tme@rn104:~$ uname -a Linux rn104 6.5.7-mvebu-370xp-tld-1 #2 PREEMPT Thu Oct 19 18:31:43 PDT 2023 armv7l GNU/Linux tme@rn104:~$ cat /etc/debian_version 11.9 tme@rn104:~$ uptime 12:02:15 up 3 min, 1 user, load average: 0.08, 0.17, 0.08 tme@rn104:~by tme - Debian
Hi Jungle, I've checked my RN104 which is normally remote. It has indeed two Ehernet ports. Only the upper one is connected. Linux detects it as "eth0". I see no RX buffer overrun on this box neighter, but the kernel version is not the very latest. tme@rn104:~$ uname -a Linux rn104 6.4.11-mvebu-370xp-tld-1 #1 PREEMPT Mon Aug 21 16:34:49 PDT 2023 armv7l GNU/Linux tme@rn104by tme - Debian
Hi bodhi, I see. Sorry for overlooking the details! I strongly believe the cause of the lagging system clock must be inside the SOC since apparently time is lagging as soon as the kernel starts its internal timer (see https://forum.doozan.com/read.php?2,133814,133889#msg-133889 above). Regards, Trond Melenby tme - Debian
Hi bodhi, QuoteThe significant difference between the Mirabox and this RN 102/104 is: the oscillator. IIRC, the SOC in Mirabox is a stripped down version of the one in RN 102/104, so the oscillators are the same. If the DTSs are different, Mirabox seems to have the right one. Yes? Regards, Trond Melenby tme - Debian
Hi Jungle, This is the thread about the system clock lagging on RN102/RN104: https://forum.doozan.com/read.php?2,133814 My current main hypothesis is that one of the unused modules in the SOC is not properly disabled and generates spurious interrupts that causes the kernel to sometimes miss the timer interrupts that updates the 64 bit system clock. It's thinkable that the same spuriousby tme - Debian
Hi bodhi, QuoteHave you seen this problem that Jugle is seeing with networkk receive buffer overrun? No, I have not: tme@rn102:~$ uptime 19:45:39 up 5 days, 5:10, 2 users, load average: 0.00, 0.00, 0.00 tme@rn102:~$ dmesg | grep overrun tme@rn102:~$ IIRC, RN104 has two ethenet ports, while RN102 has one. The SOC has two interfaces on both. Could it be that the overrun occurs on tby tme - Debian
Hi bodhi, QuoteI just don't like to see the kernel bootargs being messed up. I halted U-Boot, modified "sata_set_bootargs" and booted five times: root@rn102:~# dmesg | grep mtdparts | fold -sw 80 [ 0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial mtdparts=pxa3xx_nand-0:0x180000@0(u-boot),0x20000@0x180000(u-boot-enby tme - Debian
Hi bodhi, QuoteI think you might be right about the timing difference. I ran the new kernel on the Mirabox for a day, and saw no BUG. When the line "BUG: scheduling while atomic" appears on the serial console (and later in the 'dmesg' output), it is always between 27 s and 30 s into the kernel boot. It is always followed by two debug stack dumps as in the attachment to thby tme - Debian
Hi bodhi, I'm sorry for this slow response! And sorry for having forgotten that modifications to the U-Boot environment are volatile until saved. I've experimented a little. The BUG-line come and go. Sometimes there is no such line, sometimes it refers to "mdadm" and sometimes it refers to "kworker". These lines are from 10 reboots with no modifications to theby tme - Debian
Hi bodhi, The full serial console is attached. This is the U-Boot dialog: Marvell>> printenv mtdparts sata_set_bootargs mtdparts=mtdparts=armada-nand:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs) sata_sby tme - Debian
Hi bodhi, Thanks for your advice! The BUG message in the 'dmesg' output is now gone. Attached output on the serial console. There are still some warnings printed in bold on the serial console: [ 1.990632] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 2.000817] debugfs: Directory 'd0018100.gpio' with parent 'regmap&by tme - Debian
Hi bodhi, Where does the extra environment variables come from? As I understand, these are the only environment variables that are actually used by 'U-Boot' when booting: $ sudo fw_printenv | egrep -i 'bootcmd=|sata_set_bootargs=|sata_boot=|mtdparts=|load_uimage=|load_uinitrd=' | sort bootcmd=ide reset; run sata_bootcmd; reset load_uimage=ext2load ide 0:1 0x2000000 /bby tme - Debian
Thanks bodhi, for continuing supporting the Netgear ReadyNAS! Following the procedure in the 1st post, I upgraded one of my RN102 boxes to Linux kernel version 6.8.7. The box booted fine and I could log in using 'ssh' and copy files using 'scp', so the new kernel basically works. Examining the 'dmesg' output (attached), I discovered two debug traces, though, afby tme - Debian
Hi bodhi, Thank you very much for your efforts! I have successfully installed Linux kernel version 'linux-6.7.5-mvebu-370xp-tld-3' on a Readynas RN102. It works a expected. To check the system clock, I disabled the 'crontab' job that updates the system clock from the hardware clock once a minute. I also made the RN102 trust my laptop so that 'ssh' works withoutby tme - Debian
Nice project, whitepawn. I wish you good luck, and hope you succeed!by tme - Debian
Hi bodhi, A difference in the U-Boot environment between the boxes caught my attention: $ diff /tmp/fw*.sorted 32c31 < fdt_skip_update=no --- > fdt_skip_update=yes What does 'fdt_skip_update' do to U-Boot? Which is the recommended setting? Regards, Trond Melenby tme - Debian
Hi bodhi, Quote Indeed a strange problem! Could you delete the /etc/fw_env.config file and create it again by manually typing in /dev/mtd1 0x0 0x20000 0x20000 Note that tab or space is not relevant. And "Number of sectors" is not used anymore (it should not hurt to have, though). The configuration file '/etc/fw_env.config' is just fine: $ hexdump -C /etc/fw_env.cby tme - Debian
Hi bodhi, Quote Check the modules load option on both boxes: cat /etc/initramfs-tools/initramfs.conf | grep MODULES If MODULES=dep then this rootfs started from Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2. That'd explain why the uInitrd is much smaller. The previous rootfs has MODULES=most. This configuration file is indeed different between the two boxes: $ LC_TIME= ls -Aby tme - Debian
Hi bodhi, I have successfully updated my 2nd RN102 to Linux version 6.7.5. I noticed that the size of 'uInitrd' differs significantly between the two boxes. On the 1st box: -rw-r--r-- 1 root root 5665854 Mar 1 09:13 initrd.img-6.7.5-mvebu-370xp-tld-2 -rw-r--r-- 1 root root 5665918 Mar 1 09:13 uInitrd On the 2nd: -rw-r--r-- 1 root root 10744490 Mar 1 08:53 initrd.imgby tme - Debian