Hi bodhi, Quote Not sure why the timer@20300 was spesificed in the Mirabox, there is no need for it, this could be old code for the L2 cache frequency. I installed the device tree compiler on a Netgear RN102 with you latest kernel and root file system and converted its dtb-file to dts format. There where 23 warnings: $ sudo apt-get install device-tree-compiler $ sudo dtc -I dtb -O dtsby tme - Debian
Hi bodhi, Quote One thing I'd question: is the name enx* always the pattern, or a different adapter will give you a different name pattern? As stated above, USB-to-Ethernet adapters seems to always be named 'enx0123456789ab' by the Linux kernel where '01:23:45:67:89:ab' is their MAC addresses. This is also the case for the USB 3.0 gigabit adapter (picture attached)by tme - Debian
Thanks for the boot log bodhi, As expected, booting my RN102 with a device tree for Mirabox fails, but only after 4.7 seconds: [ 4.693689][ T1] mdio_bus d0072004.mdio-mii: MDIO device at address 1 is missing. The full boot log is attached. Before that, there is a one-to-one correspondence between the RN102 and Mirabox boot log messages with just two exceptions: [ 0.000000][by tme - Debian
Thanks bodhi, for powering up your Mirabox and for running the 'urandom' test! To me it seems that the RN102 CPU and its free running timer run at the same speed as on the Mirabox. My hypothesis now is that the RN102 system clock is updated by timer interrupts from the free running timer (Timer 0) at regular intervals, and that about 1 out of 12 interrupts are missed, alternativelby tme - Debian
Hi JoeyPogoPlugE02, It's good to hear that the box arrived safely! If you connect the box to a router with DHCP and plug-and-play, you should be able to reach it with 'ssh': $ ssh root@debian or $ ssh root@debian.local Or you may use 'putty' from a MS Window PC. Have fun! Regards, Trond Melenby tme - Off-Topic
Hi bodhi, The two adapters in the picture are fairly different, but they are both named 'enx0123456789ab' by the kernel where '01:23:45:67:89:ab' is their MAC addresses. I assume it's universal until someone reports something else. I have a third one in order (about $8 from China) so I can report about one more in, say, 3 weeks. Regards, Trond Melenby tme - Debian
With multiple boxes around, it may be hard to remember the hostname or IP address of each box, and be certain which box one is connected to. One solution is to connect directly with a cable to the box's front USB connector. This post describes how to set up the box such that plugging a USB-to-Ethernet adapter into the front USB port and connecting it to a PC with an Ethernet cable givesby tme - Debian
I was curious about whether there were further escape sequence codes than just '+' and '-' (back light on and off). Yes, there are: tme@rn104:/tmp$ wget https://github.com/torvalds/linux/raw/master/drivers/auxdisplay/charlcd.c tme@rn104:/tmp$ grep "case.**/" charlcd.c case 'D': /* Display ON */ case 'd': /* Display OFF */ case 'C&by tme - Displays
Yes, '/dev/lcd' is the correct device, and yes, the hardware interface is direct GPIO. QuoteArnaud Ebalard The LCD module consumes 8 GPIO of the SoC. In order to get additional GPIOs to connect to front buttons and LEDs, NETGEAR has added on the main board an iomuxer connected to the I2C bus, namely a NXP PCA9554. It provides eight additional GPIOs. I assume 'lcd4linux'by tme - Displays
Hi Mijzelf, From the pictures mentioned the number of pins on the display's header connectors is 4+13=17, but the wire count of the connected flat cable is only 2+10=12. It may be very well GPIO. Regards, Trond Melenby tme - Displays
Hi again, I followed you links and tried the BWCT display configuration, also without success: root@rn104:~# ls -AlF /dev/lcd* crw-rw---- 1 root lp 10, 156 Feb 11 12:04 /dev/lcd root@rn104:~# head -8 /etc/lcd4linux.conf Display BWCT-16x2 { Driver 'BWCT' Size '16x2' Contrast 220 asc255bug 1 Icons 1 # Port 'libusb' } root@rn10by tme - Displays
Thanks, Mijzelf, for your advice! I modifyed 'Port' to '/dev/lcd' for all the three displays in 'lcd4linux.conf' and tested. The error message 'No such device or address' switched to 'Operation not permitted'. So still no success: root@drodle:~# lcd4linux -Fv LCD4Linux 0.11.0-SVN-1193 starting Error connecting to the dbus session bus: Unaby tme - Displays
Hi bodhi, My Netgear RN104 has been upgraded to your latest Linux kernel 6.1.8 for Armada 370XP. No issues. Boot log attached. Thanks! I can't find anything about it in the boot log, but the 16 by 2 character LCD display is now supported. It says "Linux-6.1.8-mveb" for about 3 seconds early in the boot process. Then it turns dark until it says "Power off." for aboutby tme - Debian
bodhi has kindly added the driver for the 16 by 2 character LCD display on the front of the Netgear RN104 in his latest Armada 370XP kernel: root@rn104:~# egrep 'AUXDISPLAY|44780' /boot/config-6.1.8-mvebu-370xp-tld-1 CONFIG_AUXDISPLAY=y CONFIG_HD44780_COMMON=y CONFIG_HD44780=y I can't find anything about the driver in the boot log, but the display is supported. It says &quby tme - Displays
Attached an image of 2 industrial grade memory sticks. Low capacity, but they endure daily loss of power for ~5 years or more.by tme - Off-Topic
Your welcome, JoeyPogoPlugE02! International postal service price table here. Up to 3 kg is NOK 472. Sadly, that's about 50% more than $30. I've been ignorant to the Vita wild herring, but I'll give it a try. Thanks for the tip! :-) Regards, Trond Melenby tme - Off-Topic
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