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

Quote

Fixed. It appears that whoever created the page for the RN104 just copied my data for the RN102!

Thanks Ray!

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

Hi bodhi,

> 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).

My RN104 currently contains only 2 disks, in the 2 left most bays. I think it has contained more before, but I'm not certain.

Regards,
Trond Melen

Thanks Trond!

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

Kernel 6.12.6-mvebu-370xp-tld-1 package has been uploaded. Please see 1st post for download link.

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

bodhi Wrote:
-------------------------------------------------------
> Kernel 6.12.6-mvebu-370xp-tld-1 package has been
> uploaded. Please see 1st post for download link.


Hi Bodhi,

Kernel works great, thks !

Additionally, I could verify that the 4 disk leds can be triggered on my RN104 :)

The leds are in inverted order, then in /etc/rc.local :

echo "ide-disk4" > /sys/class/leds/rn104:blue:sata1/trigger
echo "ide-disk3" > /sys/class/leds/rn104:blue:sata2/trigger
echo "ide-disk2" > /sys/class/leds/rn104:blue:sata3/trigger
echo "ide-disk1" > /sys/class/leds/rn104:blue:sata4/trigger

adrien60,

> Kernel works great, thks !
>
> Additionally, I could verify that the 4 disk leds
> can be triggered on my RN104 :)
>

Cool!

> The leds are in inverted order

:) as long as we know the order, and can control them, I think it's OK for now.

I'm guessing Arnaud (the original developer of the RN104 DTS) did not notice this.

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

Hi bodhi,

Thank you again!

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

BTW, did you find anything interesting related to the lagging system time in the boot log with stock firmware posted on November 19th?

Regards,
Trond Melen

Hi Trond,

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

Thanks for the report!

>
> BTW, did you find anything interesting related to
> the lagging system time in the boot log with stock
> firmware posted on November 19th?

I've briefly looked at it. The only thing stands out is in u-boot.

Quote

Shutting down unused interfaces:
GBE0
SDIO
AUDIO
TDM

I recalled we tried removing an interface (Audio) and the time lag seems to improve a bit. That was a good sign, it's consistent with your theory about interrupts still firing for unused interfaces.

When I can look at this problem again, I think we'll start with updating the DTS and DTSI for this board to remove these interfaces.

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

Hi Trond,

Please recreate your uImage using the attached DTB. And try running your timelag test.

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

Thanks bodhi,

After installing a the 6.12.6 kernel with the alternative dts-file and switching off the synchronization with the real time clock, the system clock is still lagging 49 seconds in 10 minutes:

$ ssh rn102 date && sleep 600 && ssh rn102 date
Sun 29 Dec 11:21:21 CET 2024
Sun 29 Dec 11:30:32 CET 2024

That is 4.9 s/min which is about the same as 5 months ago.

Regards,
Trond Melen

Hi Trond,

> That is 4.9 s/min which is about the same as 5
> months ago.

I recall we removed the audio controller node from the DTB and the time lag was reduced a bit. Was that 4.9 s/min ? or is 4.9 s/min the original lag?

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

Hi bodhi,

I recently setup unattended upgrades on my system, but I just remembered reading a note you made on here about having to regenerate the iniramfs:

Quote
bodhi
Warning: Watch the apt-get upgrade progress. If the apt-get upgrade results in a new initramfs, the log would shows this message:

update-initramfs: Generating /boot/initrd.img-5.13.8-mvebu-tld-1

Then you need to regenerate the uInitrd boot file:

cd /boot
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs 6.6.2-mvebu-tld-1 -d initrd.img-6.6.2-mvebu-tld-1 uInitrd

Is this going to be an issue when using unattended updates?

Thanks,
Jungle

Hi bodhi,

Quote

I recall we removed the audio controller node from the DTB and the time lag was reduced a bit. Was that 4.9 s/min ? or is 4.9 s/min the original lag?

Originally, the lagging was between 6 and 7 s/min (see https://forum.doozan.com/read.php?2,133814,133814#msg-133814).

Regards,
Trond Melen

Jungle,

> Is this going to be an issue when using unattended
> updates?

If you don't reboot automatically after unattended upgrades, then there is no problem running the system.

The potential issue is when you reboot the system after unattended upgrades. The system should boot OK with the old initramfs (in the old uInitrd). But things might have changed in the rootfs related to the Debian boot process will not be reflected in the reboot.

This is a limitation of old u-boots. We need the uInitrd (with its u-boot legacy header) to boot boxes that can not boot the initramfs image as is.

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

Ok, thanks bodhi.

Jungle

Hi Trond,

> I recall we removed the audio controller node from
> the DTB and the time lag was reduced a bit. Was
> that 4.9 s/min ? or is 4.9 s/min the original
> lag?

>
> Originally, the lagging was between 6 and 7 s/min
> (see
> https://forum.doozan.com/read.php?2,133814,133814#msg-133814).
>

Thanks! based on that, the kernel drivers seems to be the problem.

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

Hi!
Does anyone have a dump of the original memory from rn104?
I need an image of the u-boot and u-boot-env partitions.



Edited 1 time(s). Last edit at 02/07/2025 05:58AM by poluyretan.

Kernel linux-6.13.8-mvebu-370xp-tld-1-bodhi.tar.bz2 package has been uploaded.

Please see 1st post for download link.

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

bodhi Wrote:
-------------------------------------------------------
> Kernel
> linux-6.13.8-mvebu-370xp-tld-1-bodhi.tar.bz2
> package has been uploaded.
>
> Please see 1st post for download link.

As always, kernel installed without any problem ;)

Hi Bodhi,

I just found an interesting thing about Wake On Lan on RNAS104.

With stock OS, it only works on top ethernet port (the manual say "Your ReadyNAS system supports wake-on-LAN on the first Ethernet port (LAN 1) only").

Curiously I decided to try the other port (eth1), and it works !

Though :
- if a cable is plugged in first port, both port shut down at system shutdown, ethernet leds are off, wol doesn't work
- if I plug a cable in first port after shutdown, ethernet leds on second port go off, and wol stop working

adrien60,

> I just found an interesting thing about Wake On
> Lan on RNAS104.
>
> With stock OS, it only works on top ethernet port
> (the manual say "Your ReadyNAS system supports
> wake-on-LAN on the first Ethernet port (LAN 1)
> only").
>
> Curiously I decided to try the other port (eth1),
> and it works !

Nice!

So let me get this straight. Are both your Ethernet ports working normally (not counting WOL)? Is the eth0 on the top and eth1 on the bottom? what is LAN 1 (eth0 or eth1)?

When you say eth1 works, does it mean only the eth1 port is connected, and you used its MAC address to wake it up?

>
> Though :
> - if a cable is plugged in first port, both port
> shut down at system shutdown, ethernet leds are
> off, wol doesn't work
> - if I plug a cable in first port after shutdown,
> ethernet leds on second port go off, and wol stop
> working

Check if both are set to WOL enable

ethtool eth0
ethtool eth1

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

Hi bodhi,

Running your root file system on my RN104, 'eth0' is the upper Ethernet connector and 'eth1' the lower. According to 'ethtool', the wakeup-on-lan support differs between the two ports ("pg" vs." d").

tme@rn104:~$ uname -a
Linux rn104 6.12.6-mvebu-370xp-tld-1 #1 PREEMPT Sun Dec 22 16:34:11 PST 2024 armv7l GNU/Linux

tme@rn104:~$ sudo ethtool eth0 | grep -i wake
	Supports Wake-on: pg
	Wake-on: d

tme@rn104:~$ sudo ethtool eth1 | grep -i wake
	Supports Wake-on: d
	Wake-on: d

Regards,
Trond Melen

Hi Bodhi,

- eth0 is on top, eth1 on bottom

- both ports are configured same (dhcp, wol) :

root@readynas-104:~# ethtool eth0 | grep -i wake
        Supports Wake-on: pg
        Wake-on: g
root@readynas-104:~# ethtool eth1 | grep -i wake
        Supports Wake-on: pg
        Wake-on: g

root@readynas-104:~# cat /etc/network/interfaces
rename /end0=eth0

auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet dhcp
  hwaddress ether 28:C6:8E:36:17:98
  ethernet-wol g

iface eth1 inet dhcp
  hwaddress ether 28:C6:8E:36:17:99
  ethernet-wol g

- I think "LAN1" in the ReadyNAS manual is the upper port, so eth0

- Both ports work normally, they get address from DHCP, they can transfer data, ...

- The only way to have WOL working is by having only eth1 plugged at shutdown
Then the eth1 leds are lit, and I can wakeup the NAS using etherwake with eth1 MAC address

- if eth0 is plugged at shutdown, or even if I plug it after shutdown, then the eth1 leds or off, and WOL doesn't work

Hi bodhi,

I just upgraded the Linux kernel on my RN104 and my two RN102 boxes from version 6.12.6 to 6.13.8. No issues.

Thanks for your efforts!

Regards,
Trond Melen

Hi bodhi,

Quote
tme
According to 'ethtool', the wakeup-on-lan support differs between the two ports ("pg" vs." d").

Adrien60 got it right. By bringing up 'eth1' too, 'ethtool' reports the same support "pg" on both 'eth0' and 'eth1'. Sorry!

Regards,
Trond Melen

All,

> - I think "LAN1" in the ReadyNAS manual is the
> upper port, so eth0
>
> - Both ports work normally, they get address from
> DHCP, they can transfer data, ...

I think the PHY addresses must have been coded differently in stock kernel. Probably swapped, so what we call eth0 is actually eth1 and vice versa, there. Stock kernel dmesg would tell.

> - The only way to have WOL working is by having
> only eth1 plugged at shutdown
> Then the eth1 leds are lit, and I can wakeup the
> NAS using etherwake with eth1 MAC address
>
> - if eth0 is plugged at shutdown, or even if I
> plug it after shutdown, then the eth1 leds or off,
> and WOL doesn't work

It's odd. But I seem to recall something restrictive in the driver, that WOL is only work with one port, I not sure IIRC though.

It's academic, but interesting to find out: run the test with only bottom port again and see if it got assigned differently, i.e eth0.

And thanks for the report about the new kernel!

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

bodhi Wrote:
-------------------------------------------------------
> It's odd, But I seem to recall something
> restrictive in the driver, that WOL is only work
> with one port, I not sure IIRC though.
>
I think I read same somewhere

> It's academic, but interesting to find out: run
> the test with only bottom port again and see if it
> got assigned differently, i.e eth0.
>
How so?
When I boot with only bottom port plugged, it's still eth1.
The ports keep getting named eth0 and eth1, no matter if a cable is plugged or not.

Bodhi,

Here are the relevant parts in dmesg about ethernet in dmesg :

Netgear OS:

[    3.895075] mvneta d0070000.ethernet eth0: Using device tree mac address 28:c6:8e:36:17:98
[    3.897014] mvneta d0074000.ethernet eth1: Using device tree mac address 28:c6:8e:36:17:99

Debian 12:

[   38.658167] mvneta d0070000.ethernet eth0: Using random mac address fa:a1:a8:08:04:c8
[   38.877159] mvneta d0074000.ethernet eth1: Using random mac address e6:40:bf:01:8a:e9
[   40.727317] mvneta d0070000.ethernet eth0: PHY [d0072004.mdio-mii:00] driver [Marvell 88E1318S] (irq=POLL)
[   40.745527] mvneta d0070000.ethernet eth0: configuring for phy/rgmii-id link mode
[  101.797452] mvneta d0074000.ethernet eth1: PHY [d0072004.mdio-mii:01] driver [Marvell 88E1318S] (irq=POLL)
[  101.815184] mvneta d0074000.ethernet eth1: configuring for phy/rgmii-id link mode
[  103.947285] mvneta d0074000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx

I made some tests with original firmware :
eth0 is on top, eth1 on bottom, like with your custom debian.
WOL works with both ports, even with both plugged.
When powered down, only orange ethernet leds are on (with our firmware, on eth1, both green and orange leds are on)

I guess there's something about eth0 in our firmware, because when I have only eth1 plugged, I power down NAS, ethernet leds (green + orange) stay lit, and if I plug eth0 (with NAS off), leds goes off instantly.

adrien60,

> Here are the relevant parts in dmesg about
> ethernet in dmesg :
>
> Netgear OS:
>

> [    3.895075] mvneta d0070000.ethernet eth0:
> Using device tree mac address 28:c6:8e:36:17:98
> [    3.897014] mvneta d0074000.ethernet eth1:
> Using device tree mac address 28:c6:8e:36:17:99
>

>
> Debian 12:
>

> [   38.658167] mvneta d0070000.ethernet eth0:
> Using random mac address fa:a1:a8:08:04:c8
> [   38.877159] mvneta d0074000.ethernet eth1:
> Using random mac address e6:40:bf:01:8a:e9
>

That happens frequently for some boxes running modern kernels running with old u-boot. And the the reason for the script:

Quote
https://forum.doozan.com/read.php?2,32146
Note 6. Persistent MAC address (Optional):

To enable the network dynamic IP to stay consistent after each reboot, and also for faster boot. In this rootfs, a script is executed during kernel booting (in /etc/rc.local), to detect if a local MAC address was assigned during boot, and then set the persistent MAC address to what is currently defined in u-boot env ethaddr.

/root/set_persistent_mac_address

Or the specifying the MAC addr in /etc/network/interface.

I think the behavior you are seeing is due to the network driver.

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

Hi Bodhi,

I know that about MAC adresses, that's why I set them in /etc/network/interfaces.

But we can see that eth0 and eth1 are affected to same network cards between stock and your kernel.