Welcome! Log In Create A New Profile

Advanced

GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade

Posted by bodhi 
GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 06, 2019 11:47PM
The GTI Mirabox and Netgear RN102/104 boxes use a special kernel version: linux-image-x.x.x-mvebu-370xp-tld-1. Other MVEBU kernel will not work with these 2 boxes. However, the rootfs is still common to all MVEBU boxes. This post contains the download link for the kernel each time if it is released. And the installation instruction specific to each box.

Note: The GTI Mirabox is a V5 version (it is powered by 5V power supply). There is an updated model (V9) for Mirabox, and this kernel will not work on the V9 model .

Latest released kernel: linux-5.9.3-mvebu-370xp-tld-1-bodhi.tar.bz2 (26 Nov 2020)
Initial Installation: Linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2 and Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 (06 Sept 2020)

Note: If this is your first time installation, then scroll down to the 06 Sept 2020 section to begin the Initial Installation. After you've booted the box with this rootfs, you can proceed to install the latest released kernel.

Credits:

- Thanks LeggoMyEggo and rayknight for the testing efforts to bring up the GTI Mirabox box (and in various threads)
- Thanks Willy Tarreau for a very informative post about UART booting for Mirabox.
- Thanks whitepawn and tme (Trond Melen) for the testing efforts to bring up the Netgear RN102 box.
- Thanks danitool at OpenWrt site for the L2 cache and the IO Cohenrency patches.


=======================================================================

Updated 26 Nov 2020:

Kernel linux-5.9.3-mvebu-370xp-tld-1 package has been uploaded.

Warning: network performance seems to degraded a bit in this kernel (but still adequate). We are working on this issue. If you are not too worry about the this then go ahead upgrade the kernel.


New/Updated in this release:

- Incorporated L2 Cache and IO Cohenrency patches (thanks Koen for reporting this improvement by danitool at OpenWrt site).

Latest Linux kernel 5.x general release information can be found at:
LinuxChanges log


Download at Dropbox

linux-5.9.3-mvebu-370xp-tld-1-bodhi.tar.bz2

md5:
0cccfa21632c200c93e9dcb4b663baa5
sha256:
73f59449249e6266f92b2c7ca64f04ec49b9c37f251b51c56505816dbcb285c9

This tarball contains 7 files:

Quote

linux-image-5.9.3-mvebu-370xp-tld-1_1.0_armhf.deb
linux-headers-5.9.3-mvebu-370xp-tld-1_1.0_armhf.deb
zImage-5.9.3-mvebu-370xp-tld-1
config-5.9.3-mvebu-370xp-tld-1
linux-dtb-5.9.3-mvebu-370xp-tld-1.tar
linux-5.9.3-mvebu-370xp-tld-1.patch
mmu.c.patch

And as always, please verify the hash of what you've downloaded!

Installation

NOTE: the following steps are for a general kernel upgrade. For 1st time installation, please see Initial Installation (scroll down to 06 Sept 2020 section)


1. Backup your current zImage, uImage, and uInitrd. In the /boot directory, these are files for your current kernel (xx.xx.xx is the version number):
uInitrd 
uImage
zImage-xx.xx.xx-mvebu-370xp-xxx
initrd.img-xx.xx.xx-mvebu-370xp-xxx
System.map-xx.xx.xx-mvebu-370xp-xxx
vmlinuz-xx.xx.xx-mvebu-370xp-xxx
config-xx.xx.xx-mvebu-370xp-xxx
dts/

2. Extract the kernel and the DTB files in the archive:

cd /boot
tar -xjf linux-5.9.3-mvebu-370xp-tld-1-bodhi.tar.bz2
tar -xf  linux-dtb-5.9.3-mvebu-370xp-tld-1.tar

3. And install it with dpkg. Remove flash-kernel first to avoid potential problem:

cd /boot
apt-get remove flash-kernel 
dpkg -i linux-image-5.9.3-mvebu-370xp-tld-1_1.0_armhf.deb

4. Create uImage and uInitrd (kernel file initrd.img-5.9.3-mvebu-370xp-tld-1 was generated by dpkg in step 3).

(I'm using the Mirabox armada-370-mirabox.dtb here in the instruction. Please replace DTB name with armada-370-netgear-rn102.dtb if you are upgrading the Netgear RN102 box).

cd /boot
cp -a uImage uImage.bak
cp -a uInitrd uInitrd.bak    
cp -a zImage-5.9.3-mvebu-370xp-tld-1 zImage.fdt 
cat dts/armada-370-mirabox.dtb >> zImage.fdt 
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.9.3-mvebu-370xp-tld-1 -d zImage.fdt uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.9.3-mvebu-370xp-tld-1 -d initrd.img-5.9.3-mvebu-370xp-tld-1 uInitrd

5. The new uImage and uInitrd files should be created in /boot directory now. You're ready to reboot the system:
sync 
sync
sync
shutdown -r now


=======================================================================

Updated 06 Sept 2020:

Note: Please see this post and one after that for the latest DTB for the Mirabox and the RN102. These 2 DTBs have been modified (14 Nov 2020) after this kernel was released.

Download at Dropbox

linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2

md5:
17c3e1784dea18b2a3587a6ebb7aa894
sha256:
655646c0bd09b047b6c9ec198579cd2e345e19c5a8f32787a0979532a3b601d4

This tarball contains 6 files:

Quote

linux-image-5.8.5-mvebu-370xp-tld-1_1.0_armhf.deb
linux-headers-5.8.5-mvebu-370xp-tld-1_1.0_armhf.deb
zImage-5.8.5-mvebu-370xp-tld-1
config-5.8.5-mvebu-370xp-tld-1
linux-dtb-5.8.5-mvebu-370xp-tld-1.tar
linux-5.8.5-mvebu-370xp-tld-1.patch

And as always, please verify the hash of what you've downloaded!


Installation

Please scrolldown to the installation section for your box below.

I. Mirabox Intsallation (06 Sept 2020)
II. Netgear RN102 Intsallation (06 Sept 2020)


=======================================================================

I. Mirabox Intsallation
Updated 06 Sept 2020


Prerequiste

Serial console must be connected to perform the installation.

Installation Steps


A. Prepare rootfs on SD card (Using any Linux box)

1. Download rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 from the release thread and extract rootfs to an SD card (at least 4GB). See the release thread for instruction how to create rootfs.

2. Place the kernel tarball linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2 to the rootfs

Mount the rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2. Assuming the rootfs is mounted at /media/sdd1. Extract kernel files

mkdir -p /media/sdd1/usr/src/kernel
cd /media/sdd1/usr/src/kernel
Copy the downloaded linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2 to the current folder (/media/sdd1/usr/src/kernel).

And then extract it:
tar xf linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2

3. Make uImage for first boot

cd /media/sdd1/usr/src/kernel
tar -xvf linux-dtb-5.8.5-mvebu-370xp-tld-1.tar dts/armada-370-mirabox.dtb
cp -a zImage-5.8.5-mvebu-370xp-tld-1 zImage.fdt
cat dts/armada-370-mirabox.dtb >> zImage.fdt 
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.8.5-mvebu-370xp-tld-1 -d zImage.fdt uImage

4. Copy uImage to rootfs boot folder

cd /media/sdd1/boot
cp -a /media/sdd1/usr/src/kernel/uImage .
sync
sync
sync
Umount and remove the SD rootfs.

B. Boot the Mirabox with new kernel

1. Plug in the new SD roots to the external SD slot. Connect serial console. Power up and interrupt serial console at count down. And

printenv
Copy and paste the list of the envs from above command in a notepad. And then,
setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 $mtdparts ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs"'
setenv bootcmd_stock 'echo Booting Stock...; nand read 0x6400000 0x400000 0x400000; run set_bootargs_stock; bootm 0x6400000'
setenv load_image_addr 0x6400000
setenv load_initrd_addr 0x8400000
setenv load_uImage 'ext2load usb 1:1 $load_image_addr /boot/uImage'
setenv load_uInitrd 'ext2load usb 1:1 $load_initrd_addr /boot/uInitrd'
setenv set_bootargs_debian 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=pxa3xx_nand-0:4M(u-boot),4M(linux),-(filesystem) earlyprintk=serial'
setenv bootcmd_debian 'echo Booting Debian... ; usb start; run load_uImage; run load_uInitrd; run set_bootargs_debian; bootm $load_image_addr $load_initrd_addr'
setenv bootcmd 'run bootcmd_debian; run bootcmd_stock'

And then go ahead with booting to Debian
boot

2. Login using SSH or serial console with root/root credential

Find the Mirabox dynamic IP address in the network. Or try to ping its hostname
ping debian.local

Log in and check what kernel is running.
uname -a
Expect Output:
Linux version 5.8.5-mvebu-370xp-tld-1 (root@tldDebianVM) (arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0, GNU ld (GNU Binutils for Ubuntu) 2.30) #1.0 SMP PREEMPT Mon Aug 31 00:00:32 PDT 2020

At this point the system is running with the new kernel 5.8.5-mvebu-370xp-tld-1, but with older rootfs.

3. Install full kernel

cd /boot
cp -a uImage uImage.mirabox.bak
cp -a uInitrd uInitrd.bak    
dpkg -i /usr/src/kernel/linux-image-5.8.5-mvebu-370xp-tld-1_1.0_armhf.deb 
tar xf /usr/src/kernel/linux-dtb-5.8.5-mvebu-370xp-tld-1.tar 
cp -a /usr/src/kernel/zImage-5.8.5-mvebu-370xp-tld-1 .
cp -a zImage-5.8.5-mvebu-370xp-tld-1 zImage.fdt 
cat dts/armada-370-mirabox.dtb >> zImage.fdt 
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.8.5-mvebu-370xp-tld-1 -d zImage.fdt uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.8.5-mvebu-370xp-tld-1 -d initrd.img-5.8.5-mvebu-370xp-tld-1 uInitrd

4. Setup envs for booting Debian permanently

a. Check NAND mtds
cat /proc/mtd
Expected Output:
dev:    size   erasesize  name
mtd0: 00400000 00080000 "u-boot"
mtd1: 00400000 00080000 "linux"
mtd2: 3f800000 00080000 "filesystem"

b. Set up envs area

echo "/dev/mtd0 0x100000 0x00080000 0x00080000" > /etc/fw_env.config

c. Do a sanilty check and then set the envs permanently

fw_setenv test_xxxx yes
fw_printenv test_xxxx
fw_printenv
Expected Output: If you can list the envs and they look like the envs listed in Step B.1 (with the additional test_xxxx env just set), then it's all checked out. If there is any error at this point then please stop and post question.

Go ahead set these permanently.
fw_setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 $mtdparts ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs"'
fw_setenv bootcmd_stock 'echo Booting Stock...; nand read 0x6400000 0x400000 0x400000; run set_bootargs_stock; bootm 0x6400000'
fw_setenv load_image_addr 0x6400000
fw_setenv load_initrd_addr 0x8400000
fw_setenv load_uImage 'ext2load usb 1:1 $load_image_addr /boot/uImage'
fw_setenv load_uInitrd 'ext2load usb 1:1 $load_initrd_addr /boot/uInitrd'
fw_setenv set_bootargs_debian 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=pxa3xx_nand-0:4M(u-boot),4M(linux),-(filesystem) earlyprintk=serial'
fw_setenv bootcmd_debian 'echo Booting Debian... ; usb start; run load_uImage; run load_uInitrd; run set_bootargs_debian; bootm $load_image_addr $load_initrd_addr'
fw_setenv bootcmd 'run bootcmd_debian; run bootcmd_stock'

And then print them again
fw_printenv
Copy and paster the envs to a notepad, for safe keeing.

5. Reboot

You are readdy to reboot the system.
sync
sync
sync
shutdown -r now


=======================================================================

II. Netgear RN102 Intsallation
Updated 06 Sept 2020


Prerequiste

Serial console must be connected to perform the installation.

Installation Steps


A. Prepare rootfs on USB drive (Using any Linux box)

1. Download rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 from the release thread and extract rootfs to a USB drive (at least 4GB). See the release thread for instruction how to create rootfs.


2. Place the kernel tarball linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2 to the rootfs

Mount the rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2. Assuming the rootfs is mounted at /media/sdd1. Extract kernel files

mkdir -p /media/sdd1/usr/src/kernel
cd /media/sdd1/usr/src/kernel
Copy the downloaded linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2 to the current folder (/media/sdd1/usr/src/kernel).


And then extract it:
tar xf linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2


3. Make uImage for first boot

cd /media/sdd1/usr/src/kernel
tar -xvf linux-dtb-5.8.5-mvebu-370xp-tld-1.tar dts/armada-370-netgear-rn102.dtb
cp -a zImage-5.8.5-mvebu-370xp-tld-1 zImage.fdt
cat dts/armada-370-netgear-rn102.dtb >> zImage.fdt 
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.8.5-mvebu-370xp-tld-1 -d zImage.fdt uImage


4. Copy uImage to rootfs boot folder

cd /media/sdd1/boot
cp -a /media/sdd1/usr/src/kernel/uImage .
sync
sync
sync
Umount and remove the USB rootfs.


B. Boot the RN102 with new kernel

1. Plug in the new USB roots to the front USB port. Connect serial console. Power up and interrupt serial console at count down. And

printenv
Copy and paste the list of the envs from above command in a notepad. And then,
setenv mtdparts 'mtdparts=pxa3xx_nand-0:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs)'
setenv usb_set_bootargs 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial'
setenv load_uimage 'ext2load usb 0:1 0x2000000 /boot/uImage'
setenv load_uinitrd 'ext2load usb 0:1 0x3000000 /boot/uInitrd'
setenv usb_boot 'run load_uimage; if run load_uinitrd; then bootm 0x2000000 0x3000000; else bootm 0x2000000; fi'
setenv usb_bootcmd 'run usb_set_bootargs; run usb_boot'
setenv bootcmd 'usb start; run usb_bootcmd; usb stop; reset'
setenv fdt_skip_update yes


And then go ahead with booting to Debian
boot


2. Login using SSH or serial console with root/root credential

Find the RN102 dynamic IP address in the network. Or try to ping its hostname
ping debian.local

Log in and check what kernel is running.
uname -a
Expect Output:
Linux version 5.8.5-mvebu-370xp-tld-1 (root@tldDebianVM) (arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0, GNU ld (GNU Binutils for Ubuntu) 2.30) #1.0 SMP PREEMPT Mon Aug 31 00:00:32 PDT 2020


At this point the system is running with the new kernel 5.8.5-mvebu-370xp-tld-1, but with older rootfs.

3. Install full kernel

cd /boot
cp -a uImage uImage.RN102.bak
cp -a uInitrd uInitrd.bak    
dpkg -i /usr/src/kernel/linux-image-5.8.5-mvebu-370xp-tld-1_1.0_armhf.deb 
tar xf /usr/src/kernel/linux-dtb-5.8.5-mvebu-370xp-tld-1.tar 
cp -a /usr/src/kernel/zImage-5.8.5-mvebu-370xp-tld-1 .
cp -a zImage-5.8.5-mvebu-370xp-tld-1 zImage.fdt 
cat dts/armada-370-netgear-rn102.dtb >> zImage.fdt 
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.8.5-mvebu-370xp-tld-1 -d zImage.fdt uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.8.5-mvebu-370xp-tld-1 -d initrd.img-5.8.5-mvebu-370xp-tld-1 uInitrd


4. Setup envs for booting Debian permanently

a. Check NAND mtds
cat /proc/mtd
Expected Output:
dev:    size   erasesize  name
dev:    size   erasesize  name
mtd0: 00180000 00020000 "u-boot"
mtd1: 00020000 00020000 "u-boot-env"
mtd2: 00600000 00020000 "uImage"
mtd3: 00400000 00020000 "minirootfs"
mtd4: 07400000 00020000 "ubifs"

b. Set up envs area

echo "/dev/mtd1 0x00000 0x20000 0x20000" > /etc/fw_env.config


c. Do a sanilty check and then set the envs permanently

fw_setenv test_xxxx yes
fw_printenv test_xxxx
fw_printenv
Expected Output: If you can list the envs and they look like the envs listed in Step B.1 (with the additional test_xxxx env just set), then it's all checked out. If there is any error at this point then please stop and post question.

Go ahead set these permanently.
fw_setenv mtdparts 'mtdparts=pxa3xx_nand-0:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs)'
fw_setenv usb_set_bootargs 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial'
fw_setenv load_uimage 'ext2load usb 0:1 0x2000000 /boot/uImage'
fw_setenv load_uinitrd 'ext2load usb 0:1 0x3000000 /boot/uInitrd'
fw_setenv usb_boot 'run load_uimage; if run load_uinitrd; then bootm 0x2000000 0x3000000; else bootm 0x2000000; fi'
fw_setenv usb_bootcmd 'run usb_set_bootargs; run usb_boot'
fw_setenv bootcmd 'usb start; run usb_bootcmd; usb stop; reset'
fw_setenv fdt_skip_update yes

And then print them again
fw_printenv
Copy and paster the envs to a notepad, for safe keeing.


5. Reboot

You are readdy to reboot the system.
sync
sync
sync
shutdown -r now


======== Old installation Instruction =================

I. Mirabox Intsallation


This Mirabox uses a special kernel version: linux-4.20.6-mvebu-mirabox-tld-12. Other MVEBU kernel will not work with this box.

Download at Dropbox

linux-4.20.6-mvebu-mirabox-tld-12-bodhi.tar.bz2

md5sum
8cf3d08dee09d000cf8b50b2df2f4047
sha256sum
fc4eb7a66e2af7f17f31041581fa6d106ba3da22ec643ab80a24aa352084f201

This tarball contains 6 files:

Quote

linux-image-4.20.6-mvebu-mirabox-tld-12_12.0_armhf.deb
linux-headers-4.20.6-mvebu-mirabox-tld-12_12.0_armhf.deb
zImage-4.20.6-mvebu-mirabox-tld-12
config-4.20.6-mvebu-mirabox-tld-12
linux-dtb-4.20.6-mvebu-mirabox-tld-12.tar
linux-4.20.6-mvebu-tld-1.patch


Prerequiste

Serial console must be connected to perform the installation.

Installation Steps


A. Prepare rootfs on SD card

1. Download rootfs Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2 from the release thread and extract rootfs to an SD card (at least 4GB). See the release thread for instruction how to create rootfs.

2. Copy the download Mirabox kernel tarball linux-4.20.6-mvebu-mirabox-tld-12-bodhi.tar.bz2 to rootfs

Mount the rootfs. Assuming the rootfs is mounted at /media/sdd1. Extract kernel files

mkdir -p /media/sdd1/usr/src/mirabox
cd /media/sdd1/usr/src/mirabox
tar xf linux-4.20.6-mvebu-mirabox-tld-12-bodhi.tar.bz2

3. Make Mirabox uImage for first boot

cd /media/sdd1/usr/src/mirabox
tar -xvf linux-dtb-4.20.6-mvebu-mirabox-tld-12.tar dts/armada-370-mirabox.dtb
cp zImage-4.20.6-mvebu-mirabox-tld-12 zImage.fdt
cp -a zImage-4.20.6-mvebu-mirabox-tld-12 zImage.fdt
cat dts/armada-370-mirabox.dtb >> zImage.fdt 
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-4.20.6-mvebu-mirabox-tld-12 -d zImage.fdt uImage

4. Copy Mirabox uImage to rootfs boot folder

cd /media/sdd1/boot
cp -a uImage uImage.bak
cp -a /media/sdd1/usr/src/mirabox/uImage .
sync


B. Boot the Mirabox with new kernel

1. Plug in the new SD roots to the external SD slot. Connect serial console. Power up and interrupt serial console at count down. And

printenv
Copy and paste the list of the envs from above command in a notepad. And then,
setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 $mtdparts ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs"'
setenv bootcmd_stock 'echo Booting Stock...; nand read 0x6400000 0x400000 0x400000; run set_bootargs_stock; bootm 0x6400000'
setenv load_image_addr 0x6400000
setenv load_initrd_addr 0x8400000
setenv load_uImage 'ext2load usb 1:1 $load_image_addr /boot/uImage'
setenv load_uInitrd 'ext2load usb 1:1 $load_initrd_addr /boot/uInitrd'
setenv set_bootargs_debian 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=pxa3xx_nand-0:4M(u-boot),4M(linux),-(filesystem) earlyprintk=serial'
setenv bootcmd_debian 'echo Booting Debian... ; usb start; run load_uImage; run load_uInitrd; run set_bootargs_debian; bootm $load_image_addr $load_initrd_addr'
setenv bootcmd 'run bootcmd_debian; run bootcmd_stock'

And then go ahead with booting to Debian
boot

2. Login using SSH or serial console with root/root credential

Find the Mirabox dynamic IP address in the network. Or try to ping its hostname
ping debian.local

Log in and check what kernel is running.
uname -a
Expect Output:
Linux debian 4.20.6-mvebu-mirabox-tld-12 #6 SMP PREEMPT Wed Mar 13 14:43:16 PDT 2019 armv7l GNU/Linux

At this point the system is running with the new kernel 4.20.6-mvebu-mirabox-tld-12, but with older rootfs.

3. Install full kernel

cd /boot
cp -a uImage uImage.mirabox.bak
cp -a uInitrd uInitrd.bak    
dpkg -i /usr/src/mirabox/linux-image-4.20.6-mvebu-mirabox-tld-12_12.0_armhf.deb 
tar xf /usr/src/mirabox/linux-dtb-4.20.6-mvebu-mirabox-tld-12.tar 
cp -a /usr/src/mirabox/zImage-4.20.6-mvebu-mirabox-tld-12 .
cp -a zImage-4.20.6-mvebu-mirabox-tld-12 zImage.fdt 
cat dts/armada-370-mirabox.dtb >> zImage.fdt 
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-4.20.6-mvebu-mirabox-tld-12 -d zImage.fdt uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-4.20.6-mvebu-mirabox-tld-12 -d initrd.img-4.20.6-mvebu-mirabox-tld-12 uInitrd

4. Setup envs for booting Debian permanently

a. Check NAND mtds
cat /proc/mtd
Expected Output:
dev:    size   erasesize  name
mtd0: 00400000 00080000 "u-boot"
mtd1: 00400000 00080000 "linux"
mtd2: 3f800000 00080000 "filesystem"

b. Set up envs area

echo "/dev/mtd0 0x100000 0x00080000 0x00080000" > /etc/fw_env.config

c. Do a sanilty check and then set the envs permanently

fw_setenv test_xxxx yes
fw_printenv test_xxxx
fw_printenv
Expected Output: If you can list the envs and they look like the envs listed in Step B.1 (with the additional test_xxxx env just set), then it's all checked out. If there is any error at this point then please stop and post question.

Go ahead set these permanently.
fw_setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 $mtdparts ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs"'
fw_setenv bootcmd_stock 'echo Booting Stock...; nand read 0x6400000 0x400000 0x400000; run set_bootargs_stock; bootm 0x6400000'
fw_setenv load_image_addr 0x6400000
fw_setenv load_initrd_addr 0x8400000
fw_setenv load_uImage 'ext2load usb 1:1 $load_image_addr /boot/uImage'
fw_setenv load_uInitrd 'ext2load usb 1:1 $load_initrd_addr /boot/uInitrd'
fw_setenv set_bootargs_debian 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=pxa3xx_nand-0:4M(u-boot),4M(linux),-(filesystem) earlyprintk=serial'
fw_setenv bootcmd_debian 'echo Booting Debian... ; usb start; run load_uImage; run load_uInitrd; run set_bootargs_debian; bootm $load_image_addr $load_initrd_addr'
fw_setenv bootcmd 'run bootcmd_debian; run bootcmd_stock'

And then print them again
fw_printenv
Copy and paster the envs to a notepad, for safe keeing.

5. Reboot

You are readdy to reboot the system.
sync
shutdown -r now

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 15 time(s). Last edit at 11/27/2020 03:50PM by bodhi.
Re: Mirabox (Armada 370) Installation
November 17, 2019 04:52AM
This entry should probably mention that this firmware image will not work on newer versions of the Mirabox that have U-Boot on a 2MB SPI NOR chip and the OS on a 4GB eMMC on the USB bus. The unit I have also uses Realtek USB wifi instead of the Marvell on earlier units. The earlier units are powered by 5V and this later version uses 12V power. It would be nice to get a working DTS file for these later versions as they also have support for MSATA SSD. My earlier version has Mira_Box_II_V5-0-1 silkscreened on the bottom front of the circuit board while the newer version has Mira_Box_II_V9-1-1 silkscreened on the top of board near the Ethernet chips. Although Globalscale still offers the Mirabox for $149 they don't provide any source code and do not appear to respond to email requesting it.

P.S.
I do have my V5-0-1 version using this firmware booted from the microSD card.

Ray
Re: Mirabox (Armada 370) Installation
November 17, 2019 05:08AM
Ray,

> This entry should probably mention that this
> firmware image will not work on newer versions of
> the Mirabox that have U-Boot on a 2MB SPI NOR chip
> and the OS on a 4GB eMMC on the USB bus.

Thanks for the reminder!

> The unit
> I have also uses Realtek USB wifi instead of the
> Marvell on earlier units. The earlier units are
> powered by 5V and this later version uses 12V
> power.

> It would be nice to get a working DTS file
> for these later versions as they also have support
> for MSATA SSD.

It's probably not too difficult, we'll get back to that working thread and figure out a few more details.

> My earlier version has
> Mira_Box_II_V5-0-1 silkscreened on the bottom
> front of the circuit board while the newer version
> has Mira_Box_II_V9-1-1 silkscreened on the top of
> board near the Ethernet chips. Although
> Globalscale still offers the Mirabox for $149 they
> don't provide any source code and do not appear to
> respond to email requesting it.

Yes, Globalscale is not developer-friendly, to say the least!

Eventhough I think I will have an easier time building new u-boot for this box, I still prefer to struggle with the Thecus N2350 DDR4 issue, because of this reason, among many others.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation
September 02, 2020 02:58AM
FYI,

I'm revising the Installation Instruction in the 1st post.

In the mean time, if you have already installed the last kernel version on Mirabox or Netgear RN102, you can upgrade now. Please see 1st post for download link.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: Mirabox (Armada 370) Installation
September 02, 2020 06:42PM
Ray,


> It would be nice to get a working DTS file
> for these later versions as they also have support
> for MSATA SSD. My earlier version has
> Mira_Box_II_V5-0-1 silkscreened on the bottom
> front of the circuit board while the newer version
> has Mira_Box_II_V9-1-1 silkscreened on the top of
> board near the Ethernet chips.

I believe this Mirabox V9 version should work with kernel linux-5.8.5-mvebu-tld-1.

Let me make a new V9 DTB version and you can try it sometime.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 09/02/2020 06:43PM by bodhi.
Re: Mirabox (Armada 370) Installation
September 05, 2020 01:29AM
Hi Ray,

Here is the Mirabox V9 DTB and DTS.

-bodhi
===========================
Forum Wiki
bodhi's corner
Attachments:
open | download - armada-370-mirabox_v9.dtb (12.9 KB)
open | download - armada-370-mirabox_v9.dts (3.3 KB)
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 26, 2020 04:30PM
Kernel linux-5.9.3-mvebu-370xp-tld-1 package has been uploaded. Please see 1st post for download link.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 26, 2020 06:29PM
Bad iperf... compared to 5.8.5

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49012
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   679 MBytes   569 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49014
[  4]  0.0-10.0 sec   672 MBytes   563 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49016
[  4]  0.0-10.0 sec   678 MBytes   568 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49018
[  4]  0.0-10.0 sec   664 MBytes   556 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49020
[  4]  0.0-10.0 sec   670 MBytes   561 Mbits/sec

new kernel 5.9.3
---------------------------------------------------------------------------------------------------

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 44442
[  4]  0.0-10.0 sec   980 MBytes   821 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 44444
[  4]  0.0-10.0 sec   954 MBytes   800 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 44446
[  4]  0.0-10.0 sec   930 MBytes   779 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 44448
[  4]  0.0-10.0 sec   949 MBytes   796 Mbits/sec

Old Kernel 5.8.5

Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 27, 2020 06:54AM
Thanks David! I did not notice that.

-bodhi
===========================
Forum Wiki
bodhi's corner
tme
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 27, 2020 06:57AM
Hi bodhi,

This is off topic now, since the Armade 370 L2 cache issue is solved. The topic has somehow slide into Network performance in stead, so feel free the reorganize as you see fit.

I have sucessfully installed your Linux kernel 5.9.3 on my Netgear ReadyNAS RN102:
$ ssh debian.local
tme@debian.local's password: 
Linux debian 5.9.3-mvebu-370xp-tld-1 #1.0 SMP PREEMPT Tue Nov 24 20:43:55 PST 2020 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Nov 27 00:39:20 2020 from 192.168.1.50

tme@debian:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether 28:c6:8e:34:73:94 brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
4: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/tunnel6 :: brd ::
tme@debian:~$
But first I learned what happens if one installs the dtb-file for Mirabox on the RN102. The box switches itself off after about half a minute, the last line on the serial console being:
[    5.372291][    T1] mdio_bus d0072004.mdio-mii: MDIO device at address 1 is missing.
Good to know. :-)

I did some performance tests. Generating 1 GiB of zeros and discarding them now takes 0.9 s:
tme@debian:~$ dd if=/dev/zero of=/dev/null bs=32k count=32768
32768+0 records in
32768+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,93677 s, 1,1 GB/s
That is a 80% performance increase over the stock firmware! Before the kernel upgrade, the box was almost par with stock.

Generating 128 MiB of random numbers takes 5 s:
tme@debian:~$ dd if=/dev/urandom of=/dev/null bs=32k count=4096
4096+0 records in
4096+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 4,80931 s, 27,9 MB/s
This is as before the upgrade and much better than the stock firmware which needs 40 s for this task, probably lacking support for the hardware random number generator.

Sending 1 GiB of zeros from the laptop and discarding them on the box using 'netcat' on both ends takes 20 seconds as before. This is on the box:
tme@debian:~$ time nc -q 0 -l -p 2222 > /dev/null

real	0m20,338s
user	0m0,307s
sys	0m18,424s
And this is the on the laptop:
$ pv -S -s 1G /dev/zero | nc 192.168.1.39 2222
1,00GiB 0:00:20 [49,0MiB/s] [===================================================================================>] 100%            
^C
The same test with 'dd' in stead of 'pv' takes 1 s longer. So, also this kernel is not able to saturate the gigabit Ethernet when receiving. The stock kernel is able, reducing the time to 12 s. That is an annoying performance drop from stock by 33%.

Making the laptop the server, the time increases from 20 to 51 s:
tme@debian:~$ pv -S -s 1G /dev/zero | nc 192.168.1.50 2222
1,00GiB 0:00:52 [19,3MiB/s] [===================================================================================>] 100%            
^C
Replacing 'pv' with 'dd if=/dev/zero bs=32k count=32768' adds a second here too. So the receiving performance is bad, sending is worse.

Finally the 'iperf' results in both directions with default settings:
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)
------------------------------------------------------------
[  3] local 192.168.1.39 port 59142 connected with 192.168.1.50 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   721 MBytes   605 Mbits/sec
tme@debian:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.39 port 5001 connected with 192.168.1.50 port 45692
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 9.2 sec   634 MBytes   578 Mbits/sec
^C

The first test proves that this upgrade makes a real difference, but not so to the network performance. There is clearly still some work to be done. The Netgear stock firmware GPL source is available, so maybe creating a diff with their patches and studying them would be a starting point?

Regards,
Trond Melen

EDIT: Get the percentage right.



Edited 1 time(s). Last edit at 11/27/2020 11:28AM by tme.
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 27, 2020 03:47PM
All,

I suspect that the IO Coherency patch probably does not work. IIRC, there is more to this than what danitool did to turn it on.

So I will rebuild the kernel without the IO Coherency patch, and see if we got the same or better performance as 5.8.5.

I also need to get my Mirabox properly set up to see if I can get the same number that David did.

-bodhi
===========================
Forum Wiki
bodhi's corner
tme
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 04:12AM
Hi bodhi,

This, I believe, are all the Netgear patches relevant to the Ethernet driver:
diff -crw mainline/drivers/net/ethernet/marvell/Kconfig netgear/drivers/net/ethernet/marvell/Kconfig
*** mainline/drivers/net/ethernet/marvell/Kconfig	2020-11-28 09:39:13.153766986 +0100
--- netgear/drivers/net/ethernet/marvell/Kconfig	2020-02-05 08:32:17.000000000 +0100
***************
*** 72,77 ****
--- 72,105 ----
  	  To compile this driver as a module, choose M here. The module
  	  will be called pxa168_eth.
  
+ config SK98LIN
+ 	tristate "Marvell Yukon Chipset / SysKonnect SK-98xx Support"
+ 	depends on PCI
+ 	---help---
+ 	  Say Y here if you have a Marvell Yukon or SysKonnect SK-98xx/SK-95xx
+ 	  compliant Gigabit Ethernet Adapter.
+ 
+ 	  The adapters support Jumbo Frames.
+ 	  The dual link adapters support link-failover and dual port features.
+ 	  Both Marvell Yukon and SysKonnect SK-98xx/SK-95xx adapters support
+ 	  the scatter-gather functionality with sendfile(). Please refer to
+ 	  Documentation/networking/sk98lin.txt for more information about
+ 	  optional driver parameters.
+ 	  Questions concerning this driver may be addressed to:
+ 	      linux@syskonnect.de
+ 
+ 	  If you want to compile this driver as a module ( = code which can be
+ 	  inserted in and removed from the running kernel whenever you want),
+ 	  say M here and read Documentation/modules.txt. This is recommended.
+ 	  The module will be called sk98lin. This is recommended.
+ 
+ config SK98LIN_NAPI
+ 	bool "Use Rx polling (NAPI)"
+ 	depends on SK98LIN
+ 	help
+ 	  NAPI is a new driver API designed to reduce CPU and interrupt load
+ 	  when the driver is receiving lots of packets from the card.
+ 
  config SKGE
  	tristate "Marvell Yukon Gigabit Ethernet support"
  	depends on PCI
diff -crw mainline/drivers/net/ethernet/marvell/Makefile netgear/drivers/net/ethernet/marvell/Makefile
*** mainline/drivers/net/ethernet/marvell/Makefile	2020-11-28 09:39:13.153766986 +0100
--- netgear/drivers/net/ethernet/marvell/Makefile	2020-02-05 08:32:17.000000000 +0100
***************
*** 7,11 ****
--- 7,12 ----
  obj-$(CONFIG_MVNETA) += mvneta.o
  obj-$(CONFIG_MVPP2) += mvpp2.o
  obj-$(CONFIG_PXA168_ETH) += pxa168_eth.o
+ obj-$(CONFIG_SK98LIN) += sk98lin/
  obj-$(CONFIG_SKGE) += skge.o
  obj-$(CONFIG_SKY2) += sky2.o
diff -crw mainline/drivers/net/ethernet/marvell/mvmdio.c netgear/drivers/net/ethernet/marvell/mvmdio.c
*** mainline/drivers/net/ethernet/marvell/mvmdio.c	2020-11-28 09:39:13.153766986 +0100
--- netgear/drivers/net/ethernet/marvell/mvmdio.c	2020-02-05 08:32:18.000000000 +0100
***************
*** 279,284 ****
--- 279,343 ----
  	return 0;
  }
  
+ static void orion_mdio_shutdown(struct platform_device *pdev)
+ {
+ 	struct mii_bus *bus = platform_get_drvdata(pdev);
+ 	u16 rega, regb;
+ 	int i;
+ 
+ 	/* replaces /proc/power_mode_2 */
+ 	/* Force 10Mbps half duplex, disable autoneg */
+ 	for (i = 0; i < 2; i++) {
+ 		orion_mdio_write(bus, i, 0x16, 0x0);
+ 		orion_mdio_write(bus, i, 0x0, 0x8000);
+ 	}
+ 	if (system_state == SYSTEM_RESTART) {
+ 		/* Clear MII_88E1318S_PHY_LED_TCR_INT_ACTIVE_LOW, or the system
+ 		** will not reboot.  RN2120 appears to rely on a PHY link change
+ 		** interrupt to "reboot", so make sure it's enabled. */
+ 		orion_mdio_write(bus, 0, 0x16, 0x3);
+ 		rega = orion_mdio_read(bus, 0, 0x12);
+ 		regb = (rega | BIT(7)) & ~(BIT(11));
+ 	} else {
+ 		/* WoL enabled? */
+ 		orion_mdio_write(bus, 0, 0x16, 0x11);
+ 		rega = orion_mdio_read(bus, 0, 0x10);
+ 		if (rega & BIT(14)) {
+ 			/* Enable interrupt only on WOL event.
+ 			** We get an immediate poweron with large MTU without this */
+ 			for (i = 0; i < 2; i++) {
+ 				orion_mdio_write(bus, i, 0x16, 0x0);
+ 				orion_mdio_write(bus, i, 0x12, 0x80);
+ 			}
+ 			/* Magic packet enable, Clear WOL status, ..., 10BT LPM */
+ 			regb = BIT(14) | BIT(12) | BIT(10) | BIT(8) | BIT(7);
+ 			pr_debug("MII_88E1318S_PHY_WOL_CTRL: 0x%x => 0x%x\n",
+ 				rega, regb);
+ 			for (i = 0; i < 2; i++) {
+ 				orion_mdio_write(bus, i, 0x16, 0x11);
+ 				orion_mdio_write(bus, i, 0x10, regb);
+ 				orion_mdio_write(bus, i, 0x16, 0x3);
+ 			}
+ 			rega = orion_mdio_read(bus, 0, 0x12);
+ 			regb = rega | BIT(11) | BIT(7);
+ 		} else {
+ 			for (i = 0; i < 2; i++) {
+ 				orion_mdio_write(bus, i, 0x16, 0x0);
+ 				orion_mdio_write(bus, i, 0x0, BMCR_PDOWN);
+ 				orion_mdio_write(bus, i, 0x12, 0x0);
+ 				orion_mdio_write(bus, i, 0x16, 0x3);
+ 			}
+ 			rega = orion_mdio_read(bus, 0, 0x12);
+ 			regb = rega & ~(BIT(11) | BIT(7));
+ 		}
+ 	}
+ 	pr_debug("MII_88E1318S_LED_TCR: 0x%x => 0x%x\n", rega, regb);
+ 	for (i = 0; i < 2; i++) {
+ 		orion_mdio_write(bus, 0, 0x12, regb);
+ 		orion_mdio_write(bus, 0, 0x16, 0x0);
+ 	}
+ }
+ 
  static const struct of_device_id orion_mdio_match[] = {
  	{ .compatible = "marvell,orion-mdio" },
  	{ }
***************
*** 288,293 ****
--- 347,353 ----
  static struct platform_driver orion_mdio_driver = {
  	.probe = orion_mdio_probe,
  	.remove = orion_mdio_remove,
+ 	.shutdown = orion_mdio_shutdown,
  	.driver = {
  		.name = "orion-mdio",
  		.of_match_table = orion_mdio_match,
Only in netgear/drivers/net/ethernet/marvell/: mvmdio.c.orig
diff -crw mainline/drivers/net/ethernet/marvell/mvneta.c netgear/drivers/net/ethernet/marvell/mvneta.c
*** mainline/drivers/net/ethernet/marvell/mvneta.c	2020-11-28 09:39:13.153766986 +0100
--- netgear/drivers/net/ethernet/marvell/mvneta.c	2020-02-05 08:32:18.000000000 +0100
***************
*** 2930,2935 ****
--- 2930,2963 ----
  
  /* Ethtool methods */
  
+ static void
+ mvneta_eth_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+ {
+ 	struct mvneta_port *pp = netdev_priv(dev);
+ 	wol->supported = 0;
+ 	wol->wolopts = 0;
+ 	if (pp->phy_dev)
+ 		phy_ethtool_get_wol(pp->phy_dev, wol);
+ }
+ 
+ static int
+ mvneta_eth_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+ {
+ 	struct mvneta_port *pp = netdev_priv(dev);
+ 	int err;
+ 
+ 	if (pp->phy_dev == NULL)
+ 		return -EOPNOTSUPP;
+ 
+ 	err = phy_ethtool_set_wol(pp->phy_dev, wol);
+ 	/* Given that mvneta works without the marvell-specific PHY driver,
+ 	 * this debugging hint is useful to have.
+ 	 */
+ 	if (err == -EOPNOTSUPP)
+ 		netdev_info(dev, "The PHY does not support set_wol, was CONFIG_MARVELL_PHY enabled?\n");
+ 	return err;
+ }
+ 
  /* Get settings (phy address, speed) for ethtools */
  int mvneta_ethtool_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
  {
***************
*** 3100,3105 ****
--- 3128,3148 ----
  	return -EOPNOTSUPP;
  }
  
+ #ifdef CONFIG_NET_POLL_CONTROLLER
+ /* Created after drivers/net/ethernet/dec/tulip/tulip_core.c */
+ static void mvneta_poll_controller(struct net_device *dev)
+ {
+ 	struct mvneta_port *pp = netdev_priv(dev);
+ 	int irq = pp->dev->irq;
+ 
+ 	/* disable_irq here is not very nice, but with the lockless
+ 	   interrupt handler we have no other choice. */
+ 	disable_irq(irq);
+ 	mvneta_isr(irq, dev);
+ 	enable_irq(irq);
+ }
+ #endif
+ 
  static const struct net_device_ops mvneta_netdev_ops = {
  	.ndo_open            = mvneta_open,
  	.ndo_stop            = mvneta_stop,
***************
*** 3110,3115 ****
--- 3153,3161 ----
  	.ndo_fix_features    = mvneta_fix_features,
  	.ndo_get_stats64     = mvneta_get_stats64,
  	.ndo_do_ioctl        = mvneta_ioctl,
+ #ifdef CONFIG_NET_POLL_CONTROLLER
+ 	.ndo_poll_controller = mvneta_poll_controller,
+ #endif
  };
  
  const struct ethtool_ops mvneta_eth_tool_ops = {
***************
*** 3124,3129 ****
--- 3170,3177 ----
  	.get_strings	= mvneta_ethtool_get_strings,
  	.get_ethtool_stats = mvneta_ethtool_get_stats,
  	.get_sset_count	= mvneta_ethtool_get_sset_count,
+ 	.get_wol        = mvneta_eth_get_wol,
+ 	.set_wol        = mvneta_eth_set_wol,
  };
  
  /* Initialize hw */
Only in netgear/drivers/net/ethernet/marvell/: mvneta.c.orig
Only in netgear/drivers/net/ethernet/marvell/: sk98lin
diff -crw mainline/drivers/net/ethernet/marvell/sky2.c netgear/drivers/net/ethernet/marvell/sky2.c
*** mainline/drivers/net/ethernet/marvell/sky2.c	2020-11-28 09:39:13.157766985 +0100
--- netgear/drivers/net/ethernet/marvell/sky2.c	2020-02-05 08:32:18.000000000 +0100
***************
*** 2195,2200 ****
--- 2195,2201 ----
  		[FC_RX]		= "rx",
  		[FC_BOTH]	= "both",
  	};
+ 	char u4[16] = "";
  
  	sky2_set_ipg(sky2);
  
***************
*** 2210,2220 ****
  	sky2_write8(hw, SK_REG(port, LNK_LED_REG),
  		    LINKLED_ON | LINKLED_BLINK_OFF | LINKLED_LINKSYNC_OFF);
  
  	netif_info(sky2, link, sky2->netdev,
! 		   "Link is up at %d Mbps, %s duplex, flow control %s\n",
  		   sky2->speed,
  		   sky2->duplex == DUPLEX_FULL ? "full" : "half",
! 		   fc_name[sky2->flow_status]);
  }
  
  static void sky2_link_down(struct sky2_port *sky2)
--- 2211,2227 ----
  	sky2_write8(hw, SK_REG(port, LNK_LED_REG),
  		    LINKLED_ON | LINKLED_BLINK_OFF | LINKLED_LINKSYNC_OFF);
  
+ 	/* NETGEAR: Change PHY power setting to make Ultra 4 alpha gigabit work */
+ 	if (strstr(saved_command_line, "u4_alpha")) {
+ 		gm_phy_write(hw, port, PHY_MARV_EXT_CTRL_2, 0x8040);
+ 		strcpy(u4, ", ultra4-alpha");
+ 	}
+ 
  	netif_info(sky2, link, sky2->netdev,
! 		   "Link is up at %d Mbps, %s duplex, flow control %s%s\n",
  		   sky2->speed,
  		   sky2->duplex == DUPLEX_FULL ? "full" : "half",
! 		   fc_name[sky2->flow_status], u4);
  }
  
  static void sky2_link_down(struct sky2_port *sky2)
Only in netgear/drivers/net/ethernet/marvell/: sky2.c.orig

They were created by the command:
diff -crw mainline/drivers/net/ethernet/marvell/ netgear/drivers/net/ethernet/marvell/ > /tmp/mvneta-v4.4.190-netgear.diff
where
$ diff --version
diff (GNU diffutils) 3.7

$ ls -alF mainline netgear
lrwxrwxrwx 1 tme tme 13 nov.  28 09:43 mainline -> linux-stable//
lrwxrwxrwx 1 tme tme 80 nov.  28 09:44 netgear -> /home/tme/ReadyNAS-RN102/src/Netgear/ReadyNASOS_V6.10.3_WW_src/linux-4.4.190-arm/

$ (cd mainline && git status)
On branch mainline-4.4.190
nothing to commit, working tree clean

My current understanding is that the Armada 370 has no Marvell Yukon Ethernet adapter, that 'sk98lin' is an old drive and that 'sky2' is a new driver for this adapter. Further, "wol" means "wake-up on lan", which should not influence bandwidth. If so, and if the network performance drop is a driver issue, mvneta_poll_controller() is the interesting patch here.

Regards,
Trond Melen
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 05:22AM
Hi Trond,

I don't think the Netgear stock mvneta patch makes any difference any more as far as current mainline driver is concerned. I think the issue is most likely because of flow control and the network setup.

The reasoning: the Mirabox and the RN102 has identical SoC and therefore using the same network chip (is my assumption correct?), and David can get 800's Mbs with iperf test on the Mirabox (running kernel 5.8.5).

I think the most accurate test is when both the Mirabox/Netgear box and the iperf server have flow control disabled completely. The next best set up is when the Mirabox/Netgear box is the client and the iperf server has flow control disabled.

Your stock ethtool output showed that flow control was disabled completely (not even half way disabled).

....

I'll upload a new kernel soon.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 11/28/2020 05:27AM by bodhi.
tme
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 05:48AM
Hi bodhi,

Quote

The reasoning: the Mirabox and the RN102 has identical SoC and therefore using the same network chip (is my assumption correct?), and David can get 800's Mbs with iperf test on the Mirabox (running kernel 5.8.5).

I don't know about the Mirabox, but the RN102 has a Marvell 88E1318 Gigabit Ethernet PHY (ref).

800 Mb/s is better, but not good. With stock firmware the RN102 saturates a gigabit Ethernet:

Quote
tme
# iperf -c 192.168.1.200
------------------------------------------------------------
Client connecting to 192.168.1.200, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.192 port 40402 connected with 192.168.1.200 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec

Anyhow, if the network performance drop is an IO coherency issue, these Netgear patches may be the relevant ones:
*** linux-5.9.3/arch/arm/mach-mvebu/coherency.c	2020-11-28 11:42:20.978304894 +0100
--- netgear/arch/arm/mach-mvebu/coherency.c	2019-08-25 10:53:06.000000000 +0200
***************
*** 107,122 ****
  	.notifier_call = mvebu_hwcc_notifier,
  };
  
! static struct notifier_block mvebu_hwcc_pci_nb __maybe_unused = {
  	.notifier_call = mvebu_hwcc_notifier,
  };
  
! static int armada_xp_clear_l2_starting(unsigned int cpu)
  {
  	armada_xp_clear_shared_l2();
! 	return 0;
  }
  
  static void __init armada_370_coherency_init(struct device_node *np)
  {
  	struct resource res;
--- 107,130 ----
  	.notifier_call = mvebu_hwcc_notifier,
  };
  
! static struct notifier_block mvebu_hwcc_pci_nb = {
  	.notifier_call = mvebu_hwcc_notifier,
  };
  
! static int armada_xp_clear_shared_l2_notifier_func(struct notifier_block *nfb,
! 					unsigned long action, void *hcpu)
  {
+ 	if (action == CPU_STARTING || action == CPU_STARTING_FROZEN)
  		armada_xp_clear_shared_l2();
! 
! 	return NOTIFY_OK;
  }
  
+ static struct notifier_block armada_xp_clear_shared_l2_notifier = {
+ 	.notifier_call = armada_xp_clear_shared_l2_notifier_func,
+ 	.priority = 100,
+ };
+ 
  static void __init armada_370_coherency_init(struct device_node *np)
  {
  	struct resource res;
***************
*** 147,155 ****
  
  	of_node_put(cpu_config_np);
  
! 	cpuhp_setup_state_nocalls(CPUHP_AP_ARM_MVEBU_COHERENCY,
! 				  "arm/mvebu/coherency:starting",
! 				  armada_xp_clear_l2_starting, NULL);
  exit:
  	set_cpu_coherent();
  }
--- 155,162 ----
  
  	of_node_put(cpu_config_np);
  
! 	register_cpu_notifier(&armada_xp_clear_shared_l2_notifier);
! 
  exit:
  	set_cpu_coherent();
  }
***************
*** 174,180 ****
  
  	coherency_cpu_base = of_iomap(np, 0);
  	arch_ioremap_caller = armada_wa_ioremap_caller;
- 	pci_ioremap_set_mem_type(MT_UNCACHED);
  
  	/*
  	 * We should switch the PL310 to I/O coherency mode only if
--- 181,186 ----
*** linux-5.9.3/arch/arm/mach-mvebu/coherency.h	2020-11-28 11:35:42.792222332 +0100
--- netgear/arch/arm/mach-mvebu/coherency.h	2019-08-25 10:53:06.000000000 +0200
***************
*** 14,20 ****
  #ifndef __MACH_370_XP_COHERENCY_H
  #define __MACH_370_XP_COHERENCY_H
  
- extern void __iomem *coherency_base;	/* for coherency_ll.S */
  extern unsigned long coherency_phys_base;
  int set_cpu_coherent(void);
  
--- 14,19 ----
*** linux-5.9.3/arch/arm/mach-mvebu/coherency_ll.S	2020-11-28 11:42:20.978304894 +0100
--- netgear/arch/arm/mach-mvebu/coherency_ll.S	2019-08-25 10:53:06.000000000 +0200
***************
*** 66,72 ****
   * fabric registers
   */
  ENTRY(ll_get_coherency_cpumask)
! 	mrc	p15, 0, r3, cr0, cr0, 5
  	and	r3, r3, #15
  	mov	r2, #(1 << 24)
  	lsl	r3, r2, r3
--- 66,72 ----
   * fabric registers
   */
  ENTRY(ll_get_coherency_cpumask)
! 	mrc	15, 0, r3, cr0, cr0, 5
  	and	r3, r3, #15
  	mov	r2, #(1 << 24)
  	lsl	r3, r2, r3

They were generated with the command
for i in coherency.c coherency.h coherency_ll.S; do diff -cw linux-5.9.3/arch/arm/mach-mvebu/$i netgear/arch/arm/mach-mvebu/$i; done > /tmp/coherency-v5.9.3-netgear.diff

Note that this diff contains the Netgear modifications relative to the current kernel, while the 'mvneta' patches were relative to Netgear's base Linux version 4.4.190.

Regards,
Trond Melen
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 06:19AM
Hi all,

Danitool at the openwrt forum has found another performance improvement by compiling the kernel in thumb2 mode. That way he is able to saturate a gigabit ethernet connection. OpenWrt does not use this by default since it makes the kernel larger causing issues with certain devices. Details in the link below.

Koen

https://forum.openwrt.org/t/mvebu-low-performance-on-armada-370-level-2-cache-disabled/78979/8
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 06:29AM
Quote

I don't know about the Mirabox, but the RN102 has a Marvell 88E1318 Gigabit Ethernet PHY (ref).

Ah, that's a bit different, the Mirabox has 88E1510.

Quote

Anyhow, if the network performance drop is an IO coherency issue, these Netgear patches may be the relevant ones:

Yes. I think IO Coherency might be the difference between 800 and 900 Mbs.

for i in coherency.c coherency.h coherency_ll.S; do diff -cw linux-5.9.3/arch/arm/mach-mvebu/$i netgear/arch/arm/mach-mvebu/$i; done > /tmp/coherency-v5.9.3-netgear.diff

Nicely done!

But looks like the Netgear patch is a bit too hacking.

I think the right way is to do it is to lok at the Armada XP-370 coherency (slowly it came back to me what I thought about this subject before).

/usr/src/linux-5.9.3-mvebu-370xp/arch/arm/boot/dts# grep -i coherency *xp*.dts*
armada-370-xp.dtsi:			coherencyfab: coherency-fabric@20200 {
armada-370-xp.dtsi:				compatible = "marvell,coherency-fabric";

In this .dtsi, coherency-fabric is the trigger to a driver. From there it will unravel to a calling sequence of several functions.

danitool's patch might or might not be enough.

-bodhi
===========================
Forum Wiki
bodhi's corner
tme
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 06:55AM
Hi Koen,

Apparently, 'thumb2' is not set in Netgear's stock firmware:
$ grep -i thumb2 netgear/.config
# CONFIG_THUMB2_KERNEL is not set

$ ls -alF netgear
lrwxrwxrwx 1 tme tme 80 nov.  28 09:44 netgear -> /home/tme/ReadyNAS-RN102/src/Netgear/ReadyNASOS_V6.10.3_WW_src/linux-4.4.190-arm/

But maybe it should have been?

Regards,
Trond Melen
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 07:53AM
Hi Trond,

I've got a few devices running openwrt and also a few running bodhis debian but don't know much about compiling options etc. I just report what I found on the openwrt forum so the experts here can have a look at it.

Reading about thumb2 online it seems that there are benefits to it but it may not have been very mature when Netgear originally released the device. I guess they don't want to make a sudden change in compiler options between different firmware versions since it could create compatibility problems.

Koen
tme
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 12:21PM
Hi bodhi,

Quote

Ah, that's a bit different, the Mirabox has 88E1510.

I have compared Marvells Product Briefs for the two devices. They look very simular. The features highlighted are:
  • 88E1310 (RN102): "The devices support RGMII (Reduced pin count GMII for direct connection) to Copper/Fiber/SGMII with Auto-Media Detect."
  • 88E1510 (Mirabox): "In addition to supporting Energy Efficient Ethernet (EEE) on the new generation of enabled MACs, these products are also capable of implementing EEE with legacy or non-EEE devices by incorporating EEE buffering."
As I read the Briefs, 88E1510 (Mirabox) has some extra energy saving features, and that's it.

I did find the complete pdf datasheet (154 pages) for the 88E1510 (Mirabox) online, but not for the 88E1310 (RN102), so I cannot compare them in more detail.

Regards,
Trond Melen
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 03:38PM
Trond,

IIRC, both of these network chips are used in other Kirkwood devices too. So nothing really important. I just noted the difference so we can keep in mind.

According to Wikidevi the RN102 uses 88E1318, to be exact. You can also open the box and llok at the chip marking on the board.

And IMO, there is no need to use Thumb 2 for the kernel itself. FWIW, this kernel can run userspace Thumb2 binaries.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 03:58PM
To repeat my observation.

I think the most accurate test is when both the Mirabox/Netgear box and the iperf server have flow control disabled completely. The next best set up is when the Mirabox/Netgear box is the client and the iperf server has flow control completely disabled.

Note that flow contrlol could be half disabled. For example, this is on my NSA325.

root@HomeBackup:~# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: g
	Link detected: yes

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 05:12PM
Here is the tld-2 kernel. I've removed the IO Coherency patch in this kernel. So it should be identical to the 5.8.5 + new DTB.


Download at Dropbox


https://www.dropbox.com/s/ckz8fu3tocy5nkk/linux-5.9.3-mvebu-370xp-tld-2-bodhi.tar.bz2

md5sum
18372990d3fe8c26f385e199b17f19c0

sha256sum
e52259d427d65eac078401961420361ff4541e94a6d22a11635d59ab7daa9291

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 28, 2020 11:46PM
5.9.3-mvebu-370xp-tld-2's iperf is much better than 5.9.3-mvebu-370xp-tld-1's, but still not as good as 5.8.5's

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 57762
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   990 MBytes   830 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 57764
[  4]  0.0-10.0 sec   977 MBytes   819 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 57766
[  4]  0.0-10.0 sec   974 MBytes   816 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 57768
[  4]  0.0-10.0 sec   972 MBytes   815 Mbits/sec

Old 5.8.5
---------------------------------------------------------------------------------------------------

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59518
[  4]  0.0-10.0 sec   928 MBytes   778 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59520
[  4]  0.0-10.0 sec   952 MBytes   799 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59522
[  4]  0.0-10.0 sec   890 MBytes   746 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59524
[  4]  0.0-10.0 sec   921 MBytes   772 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59526
[  4]  0.0-10.0 sec   904 MBytes   758 Mbits/sec

5.9.3-mvebu-370xp-tld-2

----------------------------------------------------------------------------------------------

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49012
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   679 MBytes   569 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49014
[  4]  0.0-10.0 sec   672 MBytes   563 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49016
[  4]  0.0-10.0 sec   678 MBytes   568 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49018
[  4]  0.0-10.0 sec   664 MBytes   556 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49020
[  4]  0.0-10.0 sec   670 MBytes   561 Mbits/sec

5.9.3-mvebu-370xp-tld-1  (Copied from old data)



Edited 2 time(s). Last edit at 11/28/2020 11:48PM by daviddyer.
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 29, 2020 12:27AM
David,

Your result indicates that the IO Cohenrency patch has made it worse in 5.9.3-mvebu-370xp-tld-1.

> 5.9.3-mvebu-370xp-tld-2's iperf is much better
> than 5.9.3-mvebu-370xp-tld-1's, but still not as
> good as 5.8.5's

Regarding 5.8.5-mvebu-370xp-tld-1 vs 5.9.3-mvebu-370xp-tld-2. The only difference is the mainline kernel source. It is the same patch, kernel config and the DTS.

I don't recall there is any new config related to network. So there might have been some changes in the network driver mvneta.

======

I think it is worth it to rebuild it gain without SMP. The Armada 370 has one CPU, and we are using a kernel built specifically for this already, thus SMP is not needed.

This kernel current config was copied from the MVEBU config, which is SMP. This box is running as a UP on SMP. There is some remained overhead in this vs a non-SMP kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner
tme
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
November 29, 2020 01:55AM
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 88E1318S devices support Synchronous Ethernet (SyncE) and Precision Time Protocol (PTP)." So both 88E1310 and 88E1318 were available in a S-version capable of immediately adding a time stamp to incoming IP packages. Further, "The devices have an integrated switching voltage regulator to generate all required voltages and can run off a single 3.3V supply with the 88E1310/88E1310S supporting 2.5V/3.3V and the 88E1318/88E1318S supporting 1.8V only LVCMOS I/O Standards."

Here the current kernel configurations:
$ grep SMP ~/ReadyNAS-RN102/src/Netgear/ReadyNASOS_V6.10.3_WW_src/linux-4.4.190-arm/.config | sort
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_SMP=y
tme@debian:~$ grep SMP /boot/config-5.9.3-mvebu-370xp-tld-1 | sort
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_SMP=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_SMP=y
CONFIG_VIDEO_VP27SMPX=m

In case I'm not the only one with yet a few acronyms to learn, this is from the Linux kernel glossary:
  • SMP - Symmetric Multi-Processor: kernels compiled for multiple-CPU machines. (CONFIG_SMP=y).
  • UP - Uni-Processor: Non-SMP. (CONFIG_SMP=n).

Regards,
Trond Melen
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
December 02, 2020 04:29AM
Here is the tld-3 version. This kernel is Non-SMP. Without the IO Cohenrency patch.

Dropbox:
https://www.dropbox.com/s/yg455tqum8l2rph/linux-5.9.3-mvebu-370xp-tld-3-bodhi.tar.bz2

md5sum
67007d7202a9e57045010c862d6e13bc

sha256sum
198c713b11e8be0049cfc8267fee2631d60be6fb39f5e2c1a2852734bd1683fc

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
December 02, 2020 07:23AM
From iperf, this is the best kernel so far. At 900Mb/s level

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 57762
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   990 MBytes   830 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 57764
[  4]  0.0-10.0 sec   977 MBytes   819 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 57766
[  4]  0.0-10.0 sec   974 MBytes   816 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 57768
[  4]  0.0-10.0 sec   972 MBytes   815 Mbits/sec

Old kernel 5.8.5  (Copied from old data)
---------------------------------------------------------------------------------------------------
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 38296
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.04 GBytes   896 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 38298
[  4]  0.0-10.0 sec  1.00 GBytes   859 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 38300
[  4]  0.0-10.0 sec  1.02 GBytes   875 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 38302
[  4]  0.0-10.0 sec  1008 MBytes   845 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 38304
[  4]  0.0-10.0 sec  1.05 GBytes   899 Mbits/sec

5.9.3-mvebu-370xp-tld-3

----------------------------------------------------------------------------------------------


[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59518
[  4]  0.0-10.0 sec   928 MBytes   778 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59520
[  4]  0.0-10.0 sec   952 MBytes   799 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59522
[  4]  0.0-10.0 sec   890 MBytes   746 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59524
[  4]  0.0-10.0 sec   921 MBytes   772 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 59526
[  4]  0.0-10.0 sec   904 MBytes   758 Mbits/sec

5.9.3-mvebu-370xp-tld-2 (Copied from old data)

----------------------------------------------------------------------------------------------

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49012
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   679 MBytes   569 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49014
[  4]  0.0-10.0 sec   672 MBytes   563 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49016
[  4]  0.0-10.0 sec   678 MBytes   568 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49018
[  4]  0.0-10.0 sec   664 MBytes   556 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 49020
[  4]  0.0-10.0 sec   670 MBytes   561 Mbits/sec

5.9.3-mvebu-370xp-tld-1  (Copied from old data)
Re: GTI Mirabox and Netgear RN120 (Armada 370) Installation & Kernel Upgrade
December 02, 2020 02:44PM
Cool! it looks like a winner.

But for the sake of the last 100Mbs, I'll build tld-4 version with IO Cohenrency patch.

-bodhi
===========================
Forum Wiki
bodhi's corner
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: