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

yes i am running systemd.

shutdown -h now

gave me same results

Is your RN102 connected to a switch behind a bridge ? or is it connected to the same switch with the box running etherwake?

At the box that you use to run etherwake, try running nmap to see if the RN102 MAC address is visible.

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

I'm connected to same switch. On Original Netgear NAS OS software wake on lan is working enabled via GUI.

nmap (I've changed MAC to that wriiten on RN102 housing)

Nmap scan report for 192.168.77.124
Host is up (0.066s latency).
MAC Address: 28:C6:8E:35:5A:F7 (Netgear)

I don't have the RN102 box so I've sent Trond a PM about this topic.

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

Thank you!

i found interestin patch in Netgear ReadyNASOS kernel, is this patch included in newest kernel?

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);
	}
}

whole patch attached

pczerepaniak,

Quote

i found interestin patch in Netgear ReadyNASOS kernel, is this patch included in newest kernel?

Usually, stock kernel is old, and it would need out-of tree patches like that. Since this Armada 370 SoC and the Marvell chip 88E1318S have been in the mainline Linux for quite a long time, there should be support for things like WOL.

However, there are NAS boxes, such as the ZyXEL NSA326, in which WOL can only be activated by I2C. So the issue here is if the RN102 use the same approach. By the look of the patch you posted, it might not.

I'd like to hear from Trond after he's done some WOL testing.

===========

The released tarball includes everything you need to build your own 6.5.7 kernel (the config-6.5.7-mvebu-370xp-tld-1 and the linux-6.5.7-mvebu-370xp-tld-1.patch are all you'll need).

Quote

This tarball contains 6 files:
linux-image-6.5.7-mvebu-370xp-tld-1_1_armhf.deb
linux-headers-6.5.7-mvebu-370xp-tld-1_1_armhf.deb
zImage-6.5.7-mvebu-370xp-tld-1
config-6.5.7-mvebu-370xp-tld-1
linux-dtb-6.5.7-mvebu-370xp-tld-1.tar
linux-6.5.7-mvebu-370xp-tld-1.patch

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



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

actually, I think it was a few years ago:
https://github.com/torvalds/linux/blob/master/drivers/power/reset/linkstation-poweroff.c

I had mostly forgotten about that, I should really see if I can submit a patch to make it work for some of the kirkwood devices that use the same restart mechanism.

I've been doing the equivalent from userspace by setting the desired default values in the device tree and then setting the needed value with phytool as part of a shutdown script:


For example

&mdio
{
	phy0: ethernet-phy@0
	{
		reg = <0>;
		//LED0: on/blink on act, LED1: off (not connected) LED2: Force off (connected to power button gpio, signals shutdown/restart)
		marvell,reg-init = <0x3 0x10 0xf000 0x0881>;
	};
};

phy_restart.sh

$phytool write eth0/0/22 3
if [ "$1" == "halt" ] || [ "$1" == "poweroff" ]; then
    $phytool write eth0/0/16 0x0881
else
    $phytool write eth0/0/16 0x0981
fi
$phytool write eth0/0/22 0

I tried phy_restart.sh script with modifed devices tree and wake on lan is still not working on RN102 :/

I’d say start by confirming you can read some registers with phytool before going for a full test, somethings may need tweaking

Hi Trond,

Here is the new kernel. I've reconfigured this kernel to deselect I2S, SPDIF... (basically no sound capability). Please give it a try before I release it.

Download at Dropbox

linux-6.7.5-mvebu-370xp-tld-2-bodhi.tar.bz2

md5:
e5911eb470ecfb07b3264cb79b418673  
sha256:
fc24f03aefe8da9bf0ef4287ff6f03942ef7064c0d65b09243ed9cc272ad0f57

This tarball contains 6 files:

linux-image-6.7.5-mvebu-370xp-tld-2_2_armhf.deb
linux-headers-6.7.5-mvebu-370xp-tld-2_2_armhf.deb
zImage-6.7.5-mvebu-370xp-tld-2
config-6.7.5-mvebu-370xp-tld-2
linux-dtb-6.7.5-mvebu-370xp-tld-2.tar
linux-6.7.5-mvebu-370xp-tld-2.patch

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

Hi bodhi,

Following your directions in the first post of this thread, I have successfully installed Linux kernel version 6.7.5 on one of my Netgear RN102 file servers (mainly used as a dlna server). The root file system is on an SSD connected to the rear eSata port. This new kernel works as expected. Thanks!

The lagging system clock issue (https://forum.doozan.com/read.php?2,133814) still remains, though. I notice that there are no changes to 'dts/armada-370-netgear-rn102.dtb' since version 6.5.7 except for it's time stamp. Is this intentionally?

Is it possible to also disable TDM and the Device Bus Controller for RN102 and RN104?

For comparison with your GTI Mirabox , I have attached the RN102 'dmesg' output.

Regards,
Trond Melen

Hi Trond,

Thanks for testing!

> The lagging system clock issue
> (https://forum.doozan.com/read.php?2,133814) still
> remains, though.

Bummer.

> I notice that there are no
> changes to 'dts/armada-370-netgear-rn102.dtb'
> since version 6.5.7 except for it's time stamp. Is
> this intentionally?

Yes, I did not change the DTS, so the DTB is the same.

> Is it possible to also disable TDM and the Device
> Bus Controller for RN102 and RN104?

These are harder to do. I need to dig a bit into the kernel code for this Armada 370 SoC to see it is possible. Sound devices are easily configurable so I tried that first! Will let you know.

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

Trond & pczerepaniak,

Also I am wondering about WOL for these RN120/140. Do you see the Ethernet port LED lighted up? amber or green? And with WOL set in ethtool, when you shutdown the box, does the LED turn (or stay) amber or OFF ?

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

Hi Trond,

> > I notice that there are no
> > changes to 'dts/armada-370-netgear-rn102.dtb'
> > since version 6.5.7 except for it's time stamp.
> Is
> > this intentionally?
>
> Yes, I did not change the DTS, so the DTB is the
> same.

Perhaps I should remove those sound specific nodes in the DTS too.

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

Please use this new DTB with kernel 6.7.5-mvebu-370xp-tld-2. I've removed audio controller nodes.

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

Hi bodhi,

Where do I find the new DTB with the audio controller nodes removed?

Regards,
Trond Melen

Hi Trond,

Sorry, was being sidetracked and forgot! it is uploaded now in the post above.

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

Hi bodhi,

Booting my RN102 with the new DTB with the audio controller nodes removed failed with the message:

Error: invalid dtb and unrecognized/unsupported machine ID

The full log is attached. Did I do something wrong?

Regards,
Trond Melen

Hi Trond,

It seems there was no DTB embedded in uImage.

The zImage size is the same as your uImage in the boot log. The uImage size should be a bit larger with the DTB in it.

-rwxr-xr-x 1 root root  5099248 Feb 21 15:13 zImage-6.7.5-mvebu-370xp-tld-2

## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   Linux-6.7.5-mvebu-370xp-tld-2
   Created:      2024-02-28  21:24:10 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5099248 Bytes = 4.9 MiB

So look in your kernel installation log, perhaps you've missed that step. Recreate the uImage on the rootfs /boot will sove this.

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

Hi bodhi,

Sorry, for the mishap! I gave it a new try, and now it booted.

The system clock is still lagging, but a bit less than before. It used to be lagging 6 to 7 seconds per minute. Now it's lagging just above 5 seconds per minute.

Btw, the title of this thread has a spelling error: RN120/RN104 should read RN102/RN104.

Regards,
Trond Melen

Hi Trond,

> The system clock is still lagging, but a bit less
> than before. It used to be lagging 6 to 7 seconds
> per minute. Now it's lagging just above 5 seconds
> per minute.

That's cool! an indicator that perhaps your theory is correct.

>
> Btw, the title of this thread has a spelling
> error: RN120/RN104 should read RN102/RN104.

Thanks!

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

Hi bodhi,

I have successfully updated my 2nd RN102 to Linux version 6.7.5. I noticed that the size of 'uInitrd' differs significantly between the two boxes.

On the 1st box:

-rw-r--r--  1 root root  5665854 Mar  1 09:13 initrd.img-6.7.5-mvebu-370xp-tld-2
-rw-r--r--  1 root root  5665918 Mar  1 09:13 uInitrd

On the 2nd:

-rw-r--r--  1 root root 10744490 Mar  1 08:53 initrd.img-6.7.5-mvebu-370xp-tld-2
-rw-r--r--  1 root root 10744554 Mar  1 08:55 uInitrd

I tried to boot the 2nd box with the smaller 'uInitrd' from the 1st. It booted, but there was no network connectivity on the rear Ethernet port, so I switched back. Output of 'dmesg' is attached for both cases.

One difference between the two boxes is that the 1st was upgraded from Linux version 6.5.7, while the 2nd was upgraded from 6.4.11. May the size of uInitrd by upgrade path dependent?

Then I thought that the u-boot environment may differ between the two boxes, just to discover that 'fw_printenv' is broken on both.

$ fw_printenv
Configuration file wrong or corrupted
$ cat /etc/fw_env.config
# MTD device name	Device offset	Env. size	Flash sector size	Number of sectors
/dev/mtd1		0x0		0x20000		0x20000			1
$ cat /proc/mtd
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"

- Trond

Hi Trond,

> I have successfully updated my 2nd RN102 to Linux
> version 6.7.5. I noticed that the size of
> 'uInitrd' differs significantly between the two
> boxes.

Check the modules load option on both boxes:

cat /etc/initramfs-tools/initramfs.conf | grep MODULES

If MODULES=dep then this rootfs started from Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2. That'd explain why the uInitrd is much smaller. The previous rootfs has MODULES=most.

> I tried to boot the 2nd box with the smaller
> 'uInitrd' from the 1st. It booted, but there was
> no network connectivity on the rear Ethernet port,
> so I switched back.

I'm not sure about this, I need to look in the kernel config . But Ethernet should always work during kernel booting.

> One difference between the two boxes is that the
> 1st was upgraded from Linux version 6.5.7, while
> the 2nd was upgraded from 6.4.11. May the size of
> uInitrd by upgrade path dependent?

Not kernel upgrade. It must have been Debian initramfs settings as described above.

> Then I thought that the u-boot environment may
> differ between the two boxes, just to discover
> that 'fw_printenv' is broken on both.
>

> $ fw_printenv
> Configuration file wrong or corrupted

> $ cat /etc/fw_env.config
> # MTD device name	Device offset	Env. size	Flash
> sector size	Number of sectors
> /dev/mtd1		0x0		0x20000		0x20000			1

> $ cat /proc/mtd
> 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"
>

Indeed a strange problem! Could you delete the /etc/fw_env.config file and create it again by manually typing in

/dev/mtd1		0x0		0x20000		0x20000

Note that tab or space is not relevant. And "Number of sectors" is not used anymore (it should not hurt to have, though).

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

Hi bodhi,

Quote

Check the modules load option on both boxes:

cat /etc/initramfs-tools/initramfs.conf | grep MODULES

If MODULES=dep then this rootfs started from Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2. That'd explain why the uInitrd is much smaller. The previous rootfs has MODULES=most.

This configuration file is indeed different between the two boxes:

$ LC_TIME= ls -AlF /tmp/initramfs.conf.1st /tmp/initramfs.conf.2nd
-rw-r--r-- 1 tme tme 1582 Dec 12 23:03 /tmp/initramfs.conf.1st
-rw-r--r-- 1 tme tme 1365 Jan 14  2021 /tmp/initramfs.conf.2nd

$ diff /tmp/initramfs.conf.1st /tmp/initramfs.conf.2nd
20c20
< MODULES=dep
---
> MODULES=most
45,57d44
< 
< #
< # COMPRESSLEVEL: ...
< #
< # Set a compression level for the compressor.
< # Defaults vary by compressor.
< #
< # Valid values are:
< # 1 -  9 for gzip|bzip2|lzma|lzop
< # 0 -  9 for  lz4|xz
< # 0 - 19 for zstd
< #
< # COMPRESSLEVEL=3

However, copying '/etc/initramfs-tools/initramfs.conf' over from the 1st to the 2nd box and re-making 'uInitrd' made no difference to its size,

$ LC_TIME= ls -AlF /boot/uInitrd*
-rw-r--r-- 1 root root 10744554 Mar  2 11:25 /boot/uInitrd
-rw-r--r-- 1 root root  5665918 Mar  1 09:13 /boot/uInitrd.orig.1st
-rw-r--r-- 1 root root 10744554 Mar  1 11:11 /boot/uInitrd.orig.2nd

most likely because 'mkimage' on the 2nd box do not support 'MODULES=dep':

tme@rn102_1st:~$ cat /etc/debian_version 
12.4
tme@rn102_1st:~$ mkimage -V
mkimage version 2023.01

tme@rn102_2nd:~$ cat /etc/debian_version 
11.7
tme@rn102_2nd:~$ mkimage -V
mkimage version 2021.01+dfsg-5

So it seems 'mkimage' got a face lift in Debian Bookworm?

Regards,
Trond Melen

Hi bodhi,

Quote

Indeed a strange problem! Could you delete the /etc/fw_env.config file and create it again by manually typing in
/dev/mtd1 0x0 0x20000 0x20000
Note that tab or space is not relevant. And "Number of sectors" is not used anymore (it should not hurt to have, though).

The configuration file '/etc/fw_env.config' is just fine:

$ hexdump -C /etc/fw_env.config
00000000  23 20 4d 54 44 20 64 65  76 69 63 65 20 6e 61 6d  |# MTD device nam|
00000010  65 09 44 65 76 69 63 65  20 6f 66 66 73 65 74 09  |e.Device offset.|
00000020  45 6e 76 2e 20 73 69 7a  65 09 46 6c 61 73 68 20  |Env. size.Flash |
00000030  73 65 63 74 6f 72 20 73  69 7a 65 09 4e 75 6d 62  |sector size.Numb|
00000040  65 72 20 6f 66 20 73 65  63 74 6f 72 73 0a 2f 64  |er of sectors./d|
00000050  65 76 2f 6d 74 64 31 09  09 30 78 30 09 09 30 78  |ev/mtd1..0x0..0x|
00000060  32 30 30 30 30 09 09 30  78 32 30 30 30 30 09 09  |20000..0x20000..|
00000070  09 31 0a                                          |.1.|

Using 'strace', I found that the 'fw_printenv' error message "Configuration file wrong or corrupted" is misleading. A call to 'perror()' just after "openat(AT_FDCWD, "/dev/mtd1", O_RDONLY)" failes would give the far more informative message "Permission denied". Do you know who maintains 'fw_printenv'?

Only 'root' has access to the U-Boot environment,

$ ls -AlF /dev/mtd?
crw------- 1 root root 90, 0 Feb 29 21:14 /dev/mtd0
crw------- 1 root root 90, 2 Feb 29 21:14 /dev/mtd1
crw------- 1 root root 90, 4 Feb 29 21:14 /dev/mtd2
crw------- 1 root root 90, 6 Feb 29 21:14 /dev/mtd3
crw------- 1 root root 90, 8 Feb 29 21:14 /dev/mtd4

so 'sudo fw_printenv' works fine.

'fw_printenv' lives in '/usr/bin':

$ which fw_printenv
/usr/bin/fw_printenv

I think the solution to this issue for Debian would be to move 'fw_printenv' etc. to '/usr/sbin'. Right?

Regards,
Trond Melen

Hi bodhi,

A difference in the U-Boot environment between the boxes caught my attention:

$ diff /tmp/fw*.sorted
32c31
< fdt_skip_update=no
---
> fdt_skip_update=yes

What does 'fdt_skip_update' do to U-Boot? Which is the recommended setting?

Regards,
Trond Melen

Hi Trond,

> What does 'fdt_skip_update' do to U-Boot? Which is
> the recommended setting?

The recommended setting is

fdt_skip_update=yes

These old u-boots (on many Synology and Netgear NAS) have this customization. It updates the device tree already loaded at pre-determined location before starting kernel. We don't want u-boot to do anything extra to mess up the memory (it does bad thing to a modern kernel), so it should be "skipped". We use uImage with embedded DTB, so the Linux kernel will take care of reallocation and decompression.

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

> Using 'strace', I found that the 'fw_printenv'
> error message "Configuration file wrong or
> corrupted" is misleading. A call to 'perror()'
> just after "openat(AT_FDCWD, "/dev/mtd1",
> O_RDONLY)" failes would give the far more
> informative message "Permission denied". Do you
> know who maintains 'fw_printenv'?

Ah. That's it.

Quote
apt-cache show libubootenv-tool | grep -i maintainer

Maintainer: Nobuhiro Iwamatsu <iwamatsu@debian.org>

You could try sending email to Nobuhiro Iwamatsu. Hopefully it will be quicker, instead of Deian bug report which will take a looong time to make it way to the maintainer.

> Only 'root' has access to the U-Boot environment,

Yes.

> I think the solution to this issue for Debian
> would be to move 'fw_printenv' etc. to
> '/usr/sbin'. Right?

I've lost track of where was fw_printenv/setenv before Debian bullseyes. These commands were relocated to libubootenv-tool package (was u-boot-tools package). But I thought it always require root privilege because fw_printenv is the same binary as fw_setenv.

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