GTI Mirabox, Netgear RN102/RN104, Netgear RN2120 Installation & Kernel Upgrade (Linux-6.11.6)

Hi bodhi,

Thank you very much for your effort!

I have successfully installed Linux kernel version '6.11.6-mvebu-370xp-tld-1' on a Readynas RN102. It seems to work a expected. Output from 'dmesg' attached.

Regards,
Trond Melen

Hi Trond,

Thanks for the report! dmesg looks good.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi all,

I don't recall seeing the complete stock boot log for the RN102 or RN104. Please post this log if you have it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

Stock boot log for RN102 attached.

Regards,
Trond Melen

Thanks Trond!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

WOL topic

Looking at the RN102 stock boot log, I recall a gotcha when we tried to send the magic packet to a box to wake it up. There were instances where the manufacturers redefined the MAC address to their company's numbers, while Marvell already had a MAC address built in.

For example, this what showed in Trond's boot log.

eth1addr=28:C6:8E:XX:XX:XX
ethaddr=00:50:43:XX:XX:XX

The 1st number is Netgear's, the 2nd number is Marvell's. In this case, if you booted into Debian, eth0 MAC address is 00:50:43:XX:XX:XX then it's OK.

When we want to send the magic packet with wakeonlan, we must use the Marvell's one. Make sure that it is a Marvell's MAC address by looking up at:

https://macvendors.com

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 11/19/2024 03:09PM by bodhi.

Hello @bodhi

In my original boot args of my RN104, I have those MAC addresses:
eth1addr=28:C6:8E:XX:XX:XX
ethaddr=28:C6:8E:XX:XX:XX
mv_pon_addr=00:50:43:XX:XX:XX
yuk_ethaddr=00:00:00:XX:XX:XX

When I try WOL, I send the magic packet via my router webUI, and the router see the Netgear MAC address.

Anyway, when the NAS is powered off, there's no ethernet LED blinking, so I think the network card is not powered and that's why WOL can't work.

adrien60,

> When I try WOL, I send the magic packet via my
> router webUI, and the router see the Netgear MAC
> address.
>
> Anyway, when the NAS is powered off, there's no
> ethernet LED blinking, so I think the network card
> is not powered and that's why WOL can't work.

Is your ethernet settings look like this?

# ethtool eth0

Settings for eth0:

	Supports Wake-on: pg
	Wake-on: g
	Link detected: yes

And do you have a stock boot log?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Bodhi,

Yes my settings are same.

I don't have stock boot log, how can I get it ? (I know I'll have to change my boot args and plus an empty disk to restore the NAS stock).

adrien60,

> I don't have stock boot log, how can I get it ? (I
> know I'll have to change my boot args and plus an
> empty disk to restore the NAS stock).

Let's wait and see if Trond has it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

I did not save a stock boot log from my RN104 before installing Debian and a recent kernel on it. Sorry!

Regards,
Trond Melen

Trond,

> I did not save a stock boot log from my RN104
> before installing Debian and a recent kernel on
> it. Sorry!

That's OK. It's not a sure thing we can find the Marvell MAC address there.

adrien60,

The ethernet LED light is not reliable. I have a Kirkwood box with the Ethernet LED completely off when shutdown. But WOL still works OK. This NSA310S box also has the Ethernet chip 88E1318.

Unfortunately all my Armada 370/380 boxes all use a different Ethernet chip (88E151x).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

I did save the RN104 stock boot environment, though.

Regards,
Trond Melen

Thanks Trond!

That's good info.

Here is a Marvel MAC address.

mv_pon_addr=00:50:43:xx:xx:xx

This sounds like something we should try to send the magic packet to.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi Bodhi,

I already tried an etherwake to that MAC address and it doesn't work.

For what it's worth, I remember that with the stock firmware :
- networks leds are blinking when NAS is shutdown (only the orange one, not the green one)
- I can wake it up by sending the magic packet to the Netgear MAC

I wonder if Netgear did some patches to the kernel to keep powering the NIC/PHY in standby.

Here is attached the dmesg log of a full stock installation



Edited 1 time(s). Last edit at 11/20/2024 05:16PM by adrien60.

adrien60,

> I wonder if Netgear did some patches to the kernel
> to keep powering the NIC/PHY in standby.

They might have. But that is supposed to be in Linux mainline by now. We need to see a working WOL example from someone runing an Armada 37x/38x based NAS with the 1318 chip. The driver is mvneta.

The Kirkwood SoC driver is mv643xx_eth. I have tested this successfully with the 1318 chip.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Bodhi,

Someone indicated a patch made by Netgear on the kernel, about orion-mdio (related to the 1318 phy) here : https://forum.doozan.com/read.php?2,92514,136627#msg-136627

I don't see something equivalent in the mainline linux kernel, so I wonder if this is still relevant.

adrien60,

> Someone indicated a patch made by Netgear on the
> kernel, about orion-mdio (related to the 1318 phy)
> here :
> https://forum.doozan.com/read.php?2,92514,136627#msg-136627
>
> I don't see something equivalent in the mainline
> linux kernel, so I wonder if this is still
> relevant.

That was from pczerepaniak.

That patch never got to mainline. I wonder why. Perhaps it was rejected?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> That patch never got to mainline. I wonder why.
> Perhaps it was rejected?

I can see why it was not going to be accepted in mainline. It is too invasive and could potetially breaks other MVEBU boards.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi All,

Can I get some advice on how to clean up the rootfs?
Mine is ballooning up a bit, its now 1gb compressed.
I've cleared out the old files from the /boot dir and vacuumed journalctl and cleaned up apt.

I found the folder /usr/lib/modules contains old kernel modules and tried to remove them using apt after finding this:
stackexchange

But when I rebooted, my external usb drive (not rootfs flash drive but another) was no longer recognized.
is there a safe way to clean these up?

Thanks,
Jungle

Jungle,

> I found the folder /usr/lib/modules contains old
> kernel modules and tried to remove them using apt
> after finding this:
> stackexchange
>
> But when I rebooted, my external usb drive (not
> rootfs flash drive but another) was no longer
> recognized.
> is there a safe way to clean these up?

Don't remove the /usr/lib/modules like that. Sounds like you have never removed older kernel. The safe way is to remove the older kernel with dpkg.

List all installed kernels

dpkg -l | grep linux-image

The output looks like:

ii  linux-image-6.10.11-mvebu-tld-1:armhf 1                                       armhf        Linux kernel, version 6.10.11-mvebu-tld-1
ii  linux-image-6.11.4-mvebu-tld-1:armhf  1                                       armhf        Linux kernel, version 6.11.4-mvebu-tld-1
ii  linux-image-6.11.6-mvebu-tld-1:armhf  1                                       armhf        Linux kernel, version 6.11.6-mvebu-tld-1

To remove kernel linux-image-6.10.11-mvebu-tld-1, do

dpkg --purge linux-image-6.10.11-mvebu-tld-1

dpkg will remove any thing related to kernel 6.10.11-mvebu-tld-1 on /usr/lib/, /boot/, and any configuration files in your rootfs (pre-up, post,...). Keep 2 version of the kernels so that you can boot back to earlier working version.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Thanks bodhi!

Hi Trond,

Does all 4 drives working on your RN104? I'm wondering if the SATA PCI driver 88SE9170 on RN104 works (2 bays are connected to the PCIe bus).

But it does not work on the ReadyNAS RN2120, also has the same 88SE9170 chip

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi Bodhi,

I have 3 drives in my RN104, and they work.

BTW, I just noticed that the drives leds aren't lit up, I don't know if that's normal.

adrien60,

> I have 3 drives in my RN104, and they work.

Thanks for the report. That mean something specific in RN2120 caused the problem. The RN2120 has Armada XP SoC., while the RN104 has Armada 370 SoC. They share common characteristics, but there are differences.

>
> BTW, I just noticed that the drives leds aren't
> lit up, I don't know if that's normal.

I think you did not pay attention to the rootfs release notes!

Quote
https://forum.doozan.com/read.php?2,32146

Rootfs Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2 has been uploaded.

Basic Debian bookworm armhf rootfs for most MVEBU Armada NAS:

- tarball size: 295MB
- install size: 777MB
- The init system used in this rootfs is sysvinit . To boot with systemd, see Note 5 below.
- Installed packages: openssh-server, nano, avahi, libnss-mdns, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, locales, dialog, bzip2, nfs-kernel-server, nfs-common, iperf, ethtool, sysvinit-core, sysvinit, and sysvinit-utils, mtd-utils, u-boot-tools, libubootenv-tool, rsync, pmount, i2c-tools, qemu-arm-static (x86 version).

- see LED controls in /etc/rc.local, and /etc/init.d/halt

Set the LEDs 1 and 2 so that they blink when there are disk access.

echo "ide-disk1" > /sys/class/leds/rn2120:red:sata1
echo "ide-disk2" > /sys/class/leds/rn2120:red:sata2

The SATA3 and SATA4 LEDS cannot be controlled individually. This is something I have not done. Perhaps I can work on this and let you test it.

Set the general disks activity. So that both HDD LEDs blink when there is activity in either one.

echo "disk-activity" > /sys/class/leds/rn2120:red:sata3
echo "disk-activity" > /sys/class/leds/rn2120:red:sata4

Of course, if you have only 3 HDDs in the bays then dont set the SATA4 as above!
After you tested these settings at command line, you can add to /etc/rc.local.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 12/06/2024 01:11PM by bodhi.

Bodhi,

I tried the LEDS, it does work correctly though :
ide-disk1 correspond to the first disk from the right (ie the 4th disk)
ide-disk2 correspond to the second disk from the right (ie the 3th disk)


I think you are wrong about the RN104, it has a 88SE9215 4 port PCIE SATA controller (http://web.archive.org/web/20240420194720/http://natisbad.org/NAS3/index.html)

I read elsewhere that the RN2120 has two 88SE9170 to handle the 4 ports, and the RN102 has one 88SE9170.



Edited 1 time(s). Last edit at 12/06/2024 05:05PM by adrien60.

adrien60,

> I think you are wrong about the RN104, it has a
> 88SE9215 4 port PCIE SATA controller
> (http://web.archive.org/web/20240420194720/http://natisbad.org/NAS3/index.html)

Thanks! Then the Wikidev is quite wrong.

https://wikidevi.wi-cat.ru/Netgear_ReadyNAS_RN104

Will someone edit that page, thanks!

>
> I read elsewhere that the RN2120 has two 88SE9170
> to handle the 4 ports, and the RN102 has one
> 88SE9170.

Ah! I see that the eSATA port for both the RN104 and RN2120 is SoC native. PCIe is where all 4 drives are spun up then. I need to look at that thread (https://forum.doozan.com/read.php?2,136786) again.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

To confirm, here is the lspci of my RN104 :

00:01.0 PCI bridge: Marvell Technology Group Ltd. 88F6710 [Armada 370] ARM SoC (rev 01)
00:02.0 PCI bridge: Marvell Technology Group Ltd. 88F6710 [Armada 370] ARM SoC (rev 01)
01:00.0 USB controller: Fresco Logic FL1009 USB 3.0 Host Controller (rev 02)
02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9215 PCIe 2.0 x1 4-port SATA 6 Gb/s Controller (rev 10)

Do you have an idea why the ide-disk1 and ide-disk2 are for the 1st and 2nd drive from the right ?



Edited 1 time(s). Last edit at 12/06/2024 05:11PM by adrien60.

> To confirm, here is the lspci of my RN104 :
>
> 00:01.0 PCI bridge: Marvell Technology Group Ltd.
> 88F6710 [Armada 370] ARM SoC (rev 01)
> 00:02.0 PCI bridge: Marvell Technology Group Ltd.
> 88F6710 [Armada 370] ARM SoC (rev 01)
> 01:00.0 USB controller: Fresco Logic FL1009 USB
> 3.0 Host Controller (rev 02)
> 02:00.0 SATA controller: Marvell Technology Group
> Ltd. 88SE9215 PCIe 2.0 x1 4-port SATA 6 Gb/s
> Controller (rev 10)

Cool! great to see that's chip is working OK.

> Do you have an idea why the ide-disk1 and
> ide-disk2 are for the 1st and 2nd drive from the
> right ?

Yes (I wrote that patch). So the order of enumeration done by this PCIe controller is the SATA port 0 is the right most port physically, the next SATA port next to it is port 1. That corresponds to ide-disk1 and ide-disk2, respectively.

Usually with a 2-bay NAS, the SoC SATA controller is used, and it could assign the top/left or bottom/right to port 0 or 1.

We have no control over the order of enumeration. Same for multiple USB ports. Sometime the physical bus connections play a factor, but there is no garantee which one will spin up first.

OK, so you've inspired me to update that patch to allow 4 port LEDs individually controlled.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> adrien60,
>
> > I think you are wrong about the RN104, it has a
> > 88SE9215 4 port PCIE SATA controller
> >
> (http://web.archive.org/web/20240420194720/http://natisbad.org/NAS3/index.html)
>
> Thanks! Then the Wikidev is quite wrong.
>
> https://wikidevi.wi-cat.ru/Netgear_ReadyNAS_RN104
>
> Will someone edit that page, thanks!
Fixed. It appears that whoever created the page for the RN104 just copied my data for the RN102!