Hi All, To assess the amount of work involved in extracting the patches from the stock RN102 U-Boot and apply them to a recent U-Boot, I downloaded the mainline v2011.12 release and the Marwell/Netgear implementation to create the diff-file (attached): wget https://gitlab.denx.de/u-boot/u-boot/-/archive/v2011.12/u-boot-v2011.12.tar.bz2 tar xf u-boot-v2011.12.tar.bz2 wget https://www.downby tme - Debian
Quotewhitepawn TX and RX is enough for console. Maybe. Add GND for reliable communication. But I agree to leave 3.3 V VCC unconnected. RX of the USB-to-serial adapter should be connected to TX of the box, and vice versa. Trial and error is the easiest approach since it is harmless to get this wrong. Make sure to get GND right every time - getting this wrong may harm the box or adapter.by tme - Debian
Quotewhitepawn When I saw today's date on u-boot I had a pretty nasty smile on my face :) Wonderful! Congratulation! This is great news. To me, the most annoying shortcoming of the stock u-boot is its inability to boot from a memory stick or an SSD attached to the rear connectors, so USB3 and SATA support are on the top of my wish list for a new u-boot implementation. I understand youby tme - Debian
Quotebodhi This RN102 does not have SPI flash. whitepawn added it as a hardware mod. I see. I thought the mod was to be able to spy on the USB resets. My mistake. Regards, Trond Melenby tme - Debian
Hi bodhi, QuoteWhat is the SPI chip model? You may find out by studying the PCB pictures here. Please share your findings. Btw, do you know the current status of PaX/grsec and NX bit support mentioned on that web page and discussed in detail here for ReadyNAS Duo v2. Regards, Trond Melenby tme - Debian
Hi whitepawn, As requested, I repeated the test with an SSD in the docking station. It was a 160 GB Intel 320 Series pulled out of a Lenovo Thinkpad X220 about 3 years ago which had not been used since then. I did the installation from scratch, following my own log above, so now I've tested and verified the procedure, both with HDD and SSD (with the exception of the serial console input).by tme - Debian
Hi bodhi, Quote If you could, run your stress test using one the these 2 configurations. - With the swap file on HDD. In a chest of drawers I found a pile of old HDDs. Some where 3.5" and some 2.5". Some were 'ide' and some where 'sata'. I picked the smallest 'sata', a 100 GB Hitachi 7200 rpm HDD that was born in 2007 and spent its childhood in an Leby tme - Debian
Hi whitepawn, QuoteTrond, may I ask you to try stress command on your box with front usb attached? I tested your 'stress' command with the root file system on 4 different USB sticks: Test A: 4 GB industrial grade Innodisk (merited brand), thumb size, USB3, 11.9 MB/s. Test B: 8 GB commercial grade Tali (unmerited brand), mini, USB3(?), 4.5 MB/s. Test C: 16 GB commercial grade Leby tme - Debian
Hi bodhi, 2298 of the permanently modified files are kernel modules *.ko, and 120 of them are device tree blobs *.dtb. The remaining 28 ones are: zcat /tmp/modified-files.lst.zip | egrep -v '.ko$|.dtb$' /boot/System.map-5.8.5-mvebu-370xp-tld-1 /boot/config-5.8.5-mvebu-370xp-tld-1 /boot/initrd.img-5.8.5-mvebu-370xp-tld-1 /boot/linux-5.8.5-mvebu-370xp-tld-1.patch /boot/linux-dby tme - Debian
The attachment to previous post was too large. Here a compressed version.by tme - Debian
Hi bodhi, Confirmed. This worked: sudo su - apt install -y qemu lsblk | egrep -v '^loop' mount /dev/sdb1 /mnt cd /mnt/boot tar xf /tmp/linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2 tar xf linux-dtb-5.8.5-mvebu-370xp-tld-1.tar chroot .. bin/bash dpkg -i /boot/linux-image-5.8.5-mvebu-370xp-tld-1_1.0_armhf.deb Selecting previously unselected package linux-image-5.8.5-mvebu-3by tme - Debian
Hi bodhi, Test A: Boot with an Ethernet connection from 4 GB USB stick from Innodisk. First boot: Shutdown after 62 seconds. Last serial console output: [ 5.091676][ T1] mdio_bus d0072004.mdio-mii: MDIO device at address 1 is missing. Second boot: Shutdown after 62 seconds. Last serial console output: [ 5.093709][ T1] mdio_bus d0072004.mdio-mii: MDIO device at address 1 isby tme - Debian
Hi bodhi, Quote dpkg -i linux-image-5.8.5-mvebu-370xp-tld-1_1.0_armhf.deb That was an important step that you did not do. Thanks! I consciously postphoned this step until after the first boot (which never finished), convinced that this step on the PC would affect the PC and not the USB stick mounted on /mnt. I need to do a 'chroot' and activate 'qemu' before doing thiby tme - Debian
Hi bodhi, Quote Let me take a look at the boot logs to see why it was reset at 54 seconds. Thanks! Here are my thoughts: The last line on the serial console before the box shuts down is [ 5.695371][ T1] mdio_bus d0072004.mdio-mii: MDIO device at address 1 is missing. MDIO is about managing the Ethernet connection(s). I will check if the presence or absence of a Ethernet link duringby tme - Debian
Hi bodhi, Quote Get the mainline kernel source tree for 5.8.5 from kernel.org (or clone Linux GitHub). Apply the patch. Copy the config to the source tree. And build. I did some days ago and ended up with these results: scripts/config --disable DEBUG_INFO make clean make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j $(nproc) bindeb-pkg ls -lF .. total 32836 drwxrwxr-x 25 tme tmeby tme - Debian
Hi bodhi, Quote [ 27.104494] systemd-udevd[1710]: Could not generate persistent MAC address for eth0: No such file or directory udev name has changed to systemd-udev, but there is no systemd involved in running udev under sysvinit. Thanks! I don't want to dig deeper into this right now. Quote you can set the env ethaddr to the same MAC address as eth1addr in u-boot We agree, bby tme - Debian
Hi whitepawn, Quote Trond, may ask you to try stress command on your box with front usb attached? I did: apt install -y stress stress -cpu 1 -io 2 -vm 1 -hdd 1 --timeout 10s The USB driver reset and disconnected, but no kernel panic. The 'etx4' file system ended up in a bad state, so this test is destructive and the file system must be rebuild from scratch. Output attached inby tme - Debian
Hi bodhi, I am puzzeld by what code in the Linux 5.8.5 source tree that (see my previous post) prints [ 27.104494] systemd-udevd[1710]: Could not generate persistent MAC address for eth0: No such file or directory in the 'dmesg' log, since both these commands terminate silently: find ~/kernel/linux-5.8.5 -type f -exec grep -nHo 'systemd-udevd' {} \; find ~/kernel/lby tme - Debian
Quotetme I'm running 'systemd' rather than 'init'. No, I'm not: [ 5.792411] Run /init as init process [ 5.796597] with arguments: [ 5.796604] /init [ 5.796608] with environment: [ 5.796613] HOME=/ [ 5.796616] TERM=linux [ 5.796621] reason=normal [ 5.796624] bdtype=rn102 So even '/init' usesby tme - Debian
Hi bodhi, Spot on. Success! Thank you very much! Pasting commands both on the terminal and to my test report is clearly too much for my intellectual capacity. I have edited my latest post above and added the missing step to the last code frame. Plugged the USB-stick into RN102's front connector again and hit the power button. Logged in with 'ssh root@debian.local' when boot cby tme - Debian
Hi bodhi, I have tried to installed your Debian 5.2.9 root file system and your Linux 5.8.5 kernel from scratch on my Netgear ReadyNAS RT102. I did not succeed, but thank you very much for your efforts! For reference, this is what I did on my PC: sudo su - cd /tmp md5sum * ffe6bb6a1d591b06be1f3a55273bc236 armada-370-netgear-rn102.dtb ffa864878dd797241c0bea05d563239a Debian-5.2.9-mvby tme - Debian
Hi bodhi, Being able to build my own kernel, and boot it, would make it much easier to assist you in supporting the RT102. I solved the 'armel/armhf' issue above, but failed to make my kernel run. After u-boot wispers "Starting kernel ...", nothing happens. The error message about unrecognized/unsupported processor variant is replaced by silence. Hardly a step forward. Iby tme - Debian
Hi bodhi, A minor suggestion for your '/etc/rc.local' script: If you use -x rather than -f when testing for '/root/set_persistent_mac_address', one may disable and exnable this script with 'chmod -x' and 'chmod -x'. Nifty? EDIT: Fixed typo. Substituted -e with -x. Regards, Trond Melenby tme - Debian
Thanks bodhi, I have edited my post above and added the missing modification of the 'fw_env.config' file. QuoteSince your box use eth1 (unlike most other boxes), then script set_persistent_mac_address should use ethaddr1 and eth1. And also your /etc/network/interfaces needs updated, too. It is default to eth0 in the rootfs (this was the reason for the dhcp to go back to eth0 in yoby tme - Debian
Hi bodhi, Quotebodhi Looks like you have missed the /etc/fw_env.config new definition. Thanks a lot! I trusted you would spot the issue at a glance. Now it works. I will edit my previous post to include the 'fw_env.config' update. There still is a run away CR <13> character, but I recon we can live with that: cat /etc/fw_env.config # MTD device name Device offsetby tme - Debian
Hi bodhi, Following up this post, I have performed a fresh install of your latest Debian version, but with Linux kernel 4.20.6 and the modified device tree for the ReadyNAS RN102. Complete procedure follows mainly for my own later reference. On my Ubuntu 20.04 laptop, I downloaded the input files to /tmp/bodhi. The md5 sums were: /tmp/bodhi md5sum * ffe6bb6a1d591b06be1f3a55273bc236 arby tme - Debian
Hei bodhi, I have two RN102 units now and can thus test alternative solutions against each other for performance or other behavior. I will keep the vendor's firmware on the second one for some time to be able to compare Debian against stock. Later I will be able to compare Debian against Debian. I notice that the stock kernel uses the u-boot environment variable 'eth1addr' foby tme - Debian
Hi bodhi, I think 'keep' as 'defualt-state' in the dts-file is a good thing if is to be interpreted as "read the current state of this LED and align the driver's shadow variable with it", but maybe 'keep' means something else? 'keep' as 'default-state' cannot be blamed here because the Backup LED, which 'default-state'by tme - Debian
Hi bodhi, Reunited with my box. I can confirm whitepawn's findings on the mtd partitions. My test session listing is attached as a file. I wondered if u-boot would find a USB-stick on the USB3 connectors at the back if the stick was USB2, so I tried this. It made no difference. A working real-time clock to wake up the NAS after a power failure is important, since the unit does not bby tme - Debian
Thanks, bodhi, for your swift and detailed reply! I will, but give me a few days. I'm away from my box. Regards, Trond Melenby tme - Debian