I have a bunch of Netgear Stora boxes that I no longer use. They are all in good conditions and have all been upgraded to current firmware, including U-Boot 20017.07, Linux kernel 6.1.7 and bodhi's root file system with Debian bullseye. Some of the boxes are booting from HDD and some are booting from an industrial grade USB-stick. I only charge shipping costs. Tell me if you already have a pby tme - Off-Topic
I want to orderly shut down my boxes by pressing the power button for 5+ seconds. Sometimes, though, I realize that there is this One More Thing I want to do first, so holding it down for 10+ seconds should do nothing. I also want to see when to release the button. Attached the bash script 'power-off.sh' that, together with 'esekeyd', does the trick. It is tested on Netgear Stby tme - Debian
Hi bodhi, Today I upgraded both my RN102s to Linux 6.1.8. No issues. 'dmesg' outputs attached. Thanks! I currently do not have access to my RN104 box, but I'll upgrade it in a few weeks time. Regards, Trond Melenby tme - Debian
Hi bodhi, From drivers/clocksource/timer-armada-370-xp.c: * Timer 0 is used as free-running clocksource, while timer 1 is * used as clock_event_device. define TIMER_DIVIDER_SHIFT 5 The shifting by 5 indicates that shed_clock (timer 0) is the CPU clock divided by 64, i.e. 1.2 GHz / 64 = 18.75 MHz which gives a time resolution of 53.333... ns as expected. And from the online kerneby tme - Debian
Hi bodhi, 'rayknight' here suggests to add 2 modifications to the configuration to support the 16 by 2 character LCD display on the RN104. I'm eager to test if you provide a kernel update for the Armada 370. Regards, Trond Melenby tme - Debian
Hi bodhi, I believe it's the same for RN102, but I need to check. I checked. Contrary to what I believed, 'ide-disk1' and 'ide-disk2' work perfectly on the RN102. Sorry for my confusion! -Trondby tme - Debian
Hi boidhi, Comparing our 'dmesg' logs, I find it interesting that apparently time is lagging as soon as the kernel starts its internal timer: RN102 0 0 0.000001 0.007872 0.019438 0.024168 0.034290 0.110959 0.117666 0.126529 0.134613 0.144256 0.151252 0.158862 2.054169 2.078575 2.089990 2.099139 2.120027 2.124320 2.160606 Mby tme - Debian
Hi bodhi, There are some differences, but I find them minor compared to the observed 8% time lag: tme@t470s:~/Downloads$ grep -3 clocksource dmesg.lst [ 0.000000] kfence: initialized - using 2097152 bytes for 255 objects at 0x(ptrval)-0x(ptrval) [ 0.000000] Switching to timer-based delay loop, resolution 53ns [ 0.000001] sched_clock: 32 bits at 19MHz, resolution 53ns, wraps eveby tme - Debian
Thanks raynight, for your hints! 'lcd4linux' may become useful: tme@rn102:~$ sudo apt install -y lcd4linux tme@rn102:~$ sudo lcd4linux -l | egrep -i 'Winstar|WH1602G|hd44780|hit' BWCT : BWCT USB to HD44780 interface HD44780 : generic Noritake Soekris HD66712 LCM-162 LCD2USB : LCD2USB homebrew USB interface for HD4478by tme - Displays
The Netgear ReadyNAS RN104 has a 2 by 16 character display. It's a Winstar WH1602G LCD. Pictures here. U-boot (v2011.12) writes "NETGEAR Storage Welcome" on the display when it starts, and "Booting.." before booting Linux. This latter text sticks since Linux makes no effort to change it. The display is defined like this in the dts file: auxdisplay { compatible =by tme - Displays
Hi bodhi, I have tested your new dtb file. It failed. I did: root@rn104:/boot# cp -a uImage uImage.bak root@rn104:/boot# cp -a uInitrd uInitrd.bak root@rn104:/boot# cp -a zImage-5.19.2-mvebu-370xp-tld-1 zImage.fdt root@rn104:/boot# cat dts/armada-370-netgear-rn104.dtb >> zImage.fdt root@rn104:/boot# mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-by tme - Debian
Hi bodhi, [ 0.000001] sched_clock: 32 bits at 19MHz, resolution 53ns, wraps every 114537122277ns A 19 MHz clock has one tick per 53 ns and if has 31 bits it would wrap every 115 s. So far so good. My hunch is that the 19 MHz input clock is actually closer to 17 MHz. That would explain the observations, right? There is no relevant clock definition in 'armada-370-netgear-rn104.dtsby tme - Debian
Hi bodhi, My understanding is that the kernel reads the RTC when booting, but maintains it's own time thereafter. NTP normally compensates for drift, but on the RN102 and RN104 the drift is so large that NTP fails to compensate. Turning off NTP, the clock is measures to be about 8% slow. Letting 'cron' update the system time from the RTC once a minute limits the drift to a few sby tme - Debian
Hi bodhi, Yes, on the RN104, 'default-on' and 'none' work as expected for sata1, sata2, sata3 and sata4. 'ide-disk1' and 'ide-disk2' behaves the same as 'none', i.e. they fail. I believe it's the same for RN102, but I need to check. Regards, Trond Melenby tme - Debian
Hi bodhi, In the morning, on another RN102 (not running NTP), time and date was synchronized with its router (where NTP is working). tme@nr102:~$ sudo date -s "$(ssh root@router date -R)" root@router's password: Tue, 10 Jan 2023 09:08:28 +0100 In the evening, 11:56 h later, the system clock had fallen 1 h behind. tme@nr102:~$ ssh root@router 'hostname; date -Rby tme - Debian
Thanks bodhi! Some 20 hours ago, the time on my RN102 was synced with the time of its router (where NTP is working). Since then, its system clock has been synced with its hardware clock by 'cron' every minute. (I did the same with the RN104, but it is currently remote and inaccessible.) On the RN102: tme@rn102:~$ sudo crontab -l | tail -2 password for tme: 0 * * * * /root/rby tme - Debian
Hi bodhi, When the triggers are set to 'ide-disk1' and 'ide-disk2', LED1 and LED2 are both constantly off when copying a disk in the first compartment to another disk in the second compartment using 'rsync': tme@rn104:~$ lsblk | grep -v ^loop NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 931.5G 0 disk `-sda1 8:1 1 931.5G 0 paby tme - Debian
Hi bodhi, The clock is running about 10% too slowly on Netgear ReadyNAS RN102 and RN104. Below the transcript of the following test: My hosts 'rn104' and 'stora' share the same router and local network. Time and date on 'rn104' is synced with 'stora' using 'ssh'. 60 s later (on its own clock) 'rn104' is lagging 6 to 7 s: tme@nr1by tme - Debian
Hi bodhi, Success. Thanks! Maybe these updated dts-files should be pushed upstream? I believe the RN-104 activity LED is directly controlled by the SATA controller. It is steady on when there is no disk activity in the compartment bays, blinking when there is disk activity, and off when there are no disks present. The LED is fairly dim compared to the RN-102. The power and backup LEDs, bothby tme - Debian
Hi bodhi, I have successfully booted Linux kernel 5.19.2 and your Debian bullseye root file system from an SSD connected to the USB2 connector at the front of my Netgear ReadyNAS RN-104. Booting from the same SSD connected to the rear eSata connector, however, fails 19 seconds into the boot when the kernel should check and mount the root file system. The full serial console session is attachedby tme - Debian
Hi bodhi, I have sucessfully booted the RN-102 from an SSD connected to the eSATA port on the back of the box. The advantages compared to booting from a USB stick or an SSD connected to the USB 2.0 port at the front panel are: faster booting and higher performance, espesially when swapping memory blocks to disk the front door may be opened while the box is running to mount or hot swap raidby tme - Debian
Hi bodhi, Following you advice, I successfully did a first install of Debian using 'linux-5.19.2-mvebu-370xp-tld-1-bodhi.tar.bz2'. The log is attached for reference. U-boot detects some bad blocks, but they don't seem to interfere with the boot. Should I do something about it? NAND: (ID 0xf1ad) 128 MiB MMC: MRVL_MMC: 0 Bad block table found at page 65472, versionby tme - Debian
Hi bodhi, > Kernel linux-5.19.2-mvebu-370xp-tld-1 package has been uploaded. Please see 1st post for download link. The file 'Linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2' (see under Updated 06 Sept 2020) required for first install has been deleted from Dropbox. How do I proceed without it (i.e. without running dpkg)? Regards, Trond Melenby tme - Debian
Hi Bodhi, After a long pause, I powered up my Netgear RN-102 NAS again today and upgraded the kernel to version 5.10.7 dated 30 Jan 2021. No issues. For the bulk of MVEBU boxes, your current version is 5.18.6. Do you intend to keep Mirabox and RN-102 current in the future? The stable Debian version is now bullseye rather than buster. Is it safe to follow the standard Debian release upgrby tme - Debian
Hi wacke, Very interesting! Can you make a patch with all the differences between mainline U-Boot 2021.01 and 2021.01-00707-ge716c90229-dirty? I would be happy to test if the DDR training works on Netgear ReadyNAS RN102 as well. Regards, Trond Melenby tme - uBoot
Hi AkkJaa, QuoteIs there anti virus program for Debain? If you are worried about viruses, Debian is your savior! It's an anti virus program by itself. This article targets Debian and other Linux distributions on desktops, but most of it applies to you NAS box as well. Regards, Trond Melenby tme - uBoot
Hi bodhi, I have tested the performance of all the 4 versions of your Linux kernel 5.9.3-mvebu-370xp, as well as the stock Netgear kernel for ReadyNAS RN102. My laptop was cabled to the box via a gigabit router. All tests were performed 3 times, but only the median results are reported here. This is a summary (larger is better): A B C D E F stock 61by tme - Debian
Hi bodhi, The 'iperf' results in both directions with default settings: tme@debian:~$ uname -a Linux debian 5.9.3-mvebu-370xp-tld-3 #3.0 PREEMPT Sun Nov 29 14:33:38 PST 2020 armv7l GNU/Linux tme@debian:~$ iperf -c 192.168.1.50 ------------------------------------------------------------ Client connecting to 192.168.1.50, TCP port 5001 TCP window size: 43.8 KByte (default)by tme - Debian
Nice to hear from you again, whitepawn! Quote BTW can i quickly return to stock firmware? You still have stock U-boot on your RN102, so you should be able to activate the 'Bootmenu' and select "Factory Default" or "OS reinstall" as described here. Since the RN102 has no display, you need to check the LEDs against the table in the Hardware Manual to know when toby tme - Debian
Hi bodhi, Quote According to Wikidevi the RN102 uses 88E1318, to be exact. Correct. 88E1310 and 88E1318 are the same, though, except that the first uses 2.5 to 3.3 V signals to communicate with the MAC, while the latter uses 1.8 V signals. I'm sorry for seeding some confusion. The Marvell Alaska Product Brief covers 88E1310, 88E1310S, 88E1318 and 88E1318S: "The 88E1310S and 88Eby tme - Debian