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

Hello Trond,

Here is my U-Boot version, it is same as yours :

root@readynas-104:~# grep -a --null-data U-Boot /dev/mtd0
U-Boot 2011.12-gec25d27-dirty (Oct 26 2015 - 16:56:14) Marvell version: v2011.12 2014_T2.0p1 
06/23/2015 ReadyNAS-104 V2.0

I attach my dmesg.log.
I can see in my dmesg that I don't have the error "unsupported function audio on pin" like you.

bodhi Wrote:
-------------------------------------------------------
> Mike,
>
> > My board is I think the second of the three
> > versions of the V5. That is, it has the
> internal
> > SD slot and the reset button.
>
> Probably. I have not opened this box for many
> years, and I don't remember much about it.
>
> Here is a good article by Willy Tarreau. He was
> the first hacker for this box, I learned a lot
> from his writeup.
>
> http://wtarreau.blogspot.com/2013/02/mirabox-much-better-than-guruplug.html
>
> I think you are right about the V5 versions. I
> don't recall seeing J29.

Hi bodhi et al,

Quick update, just for information really. I cured the persistent failing to boot with the 6.17.7 kernel and my own rootfs, it seems it was an issue with RESUME UUID of a swap partition on the USB3 device.

I also cured the big boot delay when firmware-libertas is installed by patching the kernel source to disable Bluetooth AMP device. So a nice quick boot and onboard wifi too, though I guess wifi is a bit mute really.

Cheers,
Mike.
--

Mike,

> Quick update, just for information really. I cured
> the persistent failing to boot with the 6.17.7
> kernel and my own rootfs, it seems it was an issue
> with RESUME UUID of a swap partition on the USB3
> device.

Cool!

> I also cured the big boot delay when
> firmware-libertas is installed by patching the
> kernel source to disable Bluetooth AMP device. So
> a nice quick boot and onboard wifi too, though I
> guess wifi is a bit mute really.

I thought of this too, but it also disables BT for other MVEBU boxes. So if I don't care for wifi, it's simpler to remove firmare-libertas in this Mirabox rootfs.

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

adrien,

> I can see in my dmesg that I don't have the error
> "unsupported function audio on pin" like you.

I believe you are running an older version of the DTB.

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

Hello bodhi,

bodhi Wrote:
-------------------------------------------------------
> I believe you are running an older version of the
> DTB.

I think I use the latest dtb :

root@readynas-104:/boot# stat dts/armada-370-netgear-rn104.dtb 
  File: dts/armada-370-netgear-rn104.dtb
  Size: 15627           Blocks: 32         IO Block: 4096   regular file
Device: 8,1     Inode: 7340090     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-11-07 23:48:20.434579392 +0100
Modify: 2025-11-05 22:05:13.000000000 +0100
Change: 2025-11-07 23:48:20.434579392 +0100
 Birth: 2025-11-07 23:48:20.434579392 +0100

adrien,

You are right! I've added the audio node in the RN102 only. Not the RN104.

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

Hi adrien,

Your 'dmesg' log show that my RN102 and your RN104 boot at the same rate for about 2.0 s. Then my RN102 is delayed for about 1.2 s, but after this delay, the boot processes again progress at the same rate for about 0.6 s. At this point the PCI bus is polled with diverging results due to hardware differences. Attaches a file created by 'paste' where every second line is from my and your 'dmesg' logs.

Interestingly, when bodhi and I compared his Mirabox log with my RN102 log, the timestamps started diverging already after 0.008 s. So your RN104 and my RN102 report very similar boot progress, while his Mirabox differs. When it comes to system clock lagging, your RN104 and bodhi's Mirabox behave the same, while my RN102 differs. How is this possible?

I can think of three external explanations to the lack of lagging on your RN104:

1. Your RN104 and your wyse5070 are lagging at the same rate. Verifying the timing with a "wall clock" will exclude this possibility.
2. Even with 'chrony' disabled, your box is synchronized through 'ntp'. Veryfiing the lack of lagging with the box offline will exclude this possibility.
3. The system clock on your RN104 is synchronized with the box' real time clock, like my RN102 normally is by 'cron'. Not easily excluded, but worth a double check?

I find our combined observations very strange. If my RN104 was still alive, I would suggest exchanging boot images. Do you have some other ideas on how to nail down this issue?

Regards,
Trond Melen

Hi Trond,

I disabled chrony and blocked internet access from RNAS with OpenWRT, and the clock is still good, verified with my phone clock.

There is nothing in my crontab which sync the clock with the RTC (like your workaround "/sbin/hwclock -s").

I don't really know why my clock is good and yours is drifting.

Adrien

Hi Adrien,

Thanks for investigating!

This starts looking like some hardware difference. Could it be that I have an older version of the SoC than you? These are the details of my CPU:

tme@rn102:~$ lscpu | head -14
Architecture:                            armv7l
Byte Order:                              Little Endian
CPU(s):                                  1
On-line CPU(s) list:                     0
Vendor ID:                               Marvell
Model name:                              PJ4/PJ4b
Model:                                   1
Thread(s) per core:                      1
Core(s) per socket:                      1
Socket(s):                               1
Stepping:                                0x1
BogoMIPS:                                37.49
Flags:                                   half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 tls idivt
Vulnerability Gather data sampling:      Not affected

tme@rn102:~$ cat /proc/cpuinfo
processor	: 0
model name	: ARMv7 Processor rev 1 (v7l)
BogoMIPS	: 37.49
Features	: half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 tls idivt 
CPU implementer	: 0x56
CPU architecture: 7
CPU variant	: 0x1
CPU part	: 0x581
CPU revision	: 1

Hardware	: Marvell Armada 370/XP (Device Tree)
Revision	: 0000
Serial		: 0000000000000000

Regards,
Trond Melen

Hi Trond,

I have the same CPU details as you, except that :

Vendor ID:                               0x56
Model name:                              ARMv7 Processor rev 1 (v7l)

Are you running the OS on a SSD like me ?

Maybe it'll stay a mistery :)

Adrien