Disclaimer: the information provided on this page is given as is, i.e. without warranty that you will not break your system following it. Additionally, do not expect to get support and warranty from NETGEAR if this happens.

Debian and upstream kernel on NETGEAR ReadyNAS NV+ v2

This page documents some efforts to get a recent kernel and latest Debian system running on NETGEAR ReadyNAS NV+ v2, instead of the original (Marvell/NETGEAR-patched 2.6.31.8) kernel and custom system. The efforts was started at the beginning of December 2013 based on the previous work on the ReadyNAS Duo v2 and the one on ReadyNAS 104.

Note that if you are looking for a server with similarities with the ReadyNAS NV+ v2, you may in the end be interested by the following pages:

If you have comments, corrections, additional information I missed or problems w/ this page, do not hesitate to drop me a mail. Note that everything (from hardware specs to debian and kernel install) has been kept on a single page to have all the information available in a single location and be able to make a PDF out of it.

Here is the main table of contents for the page, with links to the various sections of the page.


Changelog i.e. work done

Todo list i.e. work in progress

Hardware specs

This section is dedicated to the hardware specs of the NETGEAR ReadyNAS NV+ v2. It is based on visual inspection of NV+ v2 main board and two daughter boards, completed with reading of NETGEAR 2.6.31.8 kernel sources and publicly available (read Google-gathered) information .

When available, additional information and software handling details are given for each hardware part. For instance, if you are looking for informations related to the fan controller, simply click the link above to get the details of what is used and how support is provided.

Each picture available on this page is a thumbnail of a larger picture. The larger one can be accessed by clicking the thumbnail.

If you are in a hurry looking for a specific info, you can use this table of contents to directly access information on a specific hardware part of the system or get an overview of what a NETGEAR ReadyNAS Duo v2 is made of.

The ReadyNAS NV+ v2 contains 3 cards (not including the LCD module). The main board which includes the SoC and most of the chips. It also provides the rear ports of the NAS, i.e. the GbE interface, the 2 USB 3.0 ports, the power connector, the reset button and the 3.3V serial interface.

The second card provides the four SATA ports to which the disks are connected:

The third card supports the front LEDs, power and backup buttons and USB 2.0 port

SoC

The ReadyNAS Duo v2 runs a Marvell 82F6282 SoC (aka ARMADA 300) from Kirkwood family. This SoC integrates a single core ARMv5TE-compatible CPU running at 1.6GHz (Marvell also has 1.8 and 2GHz versions). If you want to read on the subject, here are some locally cached documents: 

root@hal:~# cat /proc/cpuinfo 
Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1599.07
Features        : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Feroceon-KW
Revision        : 0000
Serial          : 0000000000000000

Hynix H5TQ1G83DFR-H9C

Two 128MB DDR3 1333 Hynix H5TQ1G83DFR-H9C chips are connected to the SoC. As you may have noticed, those chips are soldered on the board, i.e. not upgradable. Local copies of Hynix H5TQ1G83DFR specs are available.

Hynix H27U1G8F2BTR

The ReadyNAS NV+ v2 comes with 128MB of NAND flash. The chip is a Hynix H27U1G8F2BTR. If you want to get more details, the Hynix NAND flash part number decoding document is woth reading.

Marvell 88SM4140 SATA port multiplier

The picture below presents the Marvell 88SM4140 SATA port multiplier used by the device. It is located near the SoC and normally hidden under the main heatsink shared with the SoC.

Protechnic Electric Co MG9212YB-25 Fan

The ReadyNAS NV+ v2 cooling is performed by a 92mmx92mmx25mm Protechnic Electric CO MG9212YB-25 Fan.

The fan is connected to the second daughter board for power and feedback on current rotation speed (monitored by G762 fan controller).

GMT G762 Fan controller

Previous FAN is controlled by a G762 Fan controller from Global Mixed-mode Technology Inc. The G762 has many similarities with the G760a, for which support is available in upstream kernel. For those interested by the details of the device, I keep a local copy of a more detailed datasheet for the G762/G763 fan controller than the one available on GMT site.

A driver for G762 has been developed by LaCie for some of its NASes based on existing G760a driver code. Even though the driver is published under a GPLv2 license, it is currently not available in upstream kernel. Nonetheless, with minor adaptations, it integrates perfectly in current 3.8 kernel tree and allowed me to control the rotation of the fan. After quite some work with this driver as a basis, I managed to get it merged upstream in 3.11. Here is what you get on a 3.11 kernel (this is copied from my ReadyNAS Duo v2 page): 

root@hal:~# uname -a
Linux hal 3.11.0.duov2 #1 Sun Sep 8 00:01:11 CEST 2013 armv5tel GNU/Linux

After having installed lm-sensors package, we get:

root@hal:~# sensors
g762-i2c-0-3e
Adapter: mv64xxx_i2c adapter
fan1:        2082 RPM  (div = 1)

kirkwood_thermal-virtual-0
Adapter: Virtual device
temp1:        +36.7°C

root@hal:~# sensors -u
g762-i2c-0-3e
Adapter: mv64xxx_i2c adapter
fan1:
  fan1_input: 2275.000
  fan1_alarm: 0.000
  fan1_fault: 0.000
  fan1_div: 1.000
  fan1_pulses: 2.000

kirkwood_thermal-virtual-0
Adapter: Virtual device
temp1:
  temp1_input: 36.697

root@hal:/sys/bus/i2c# ls drivers
dummy  g762  rtc-rs5c372

root@hal:/sys/bus/i2c/devices/0-003e# ls
driver      fan1_div    fan1_target  modalias  pwm1         pwm1_mode  uevent
fan1_alarm  fan1_input  hwmon        name      pwm1_enable  subsystem

By playing with fan1_input et fan1_target, we can indeed modify the speed of the fan and collect its value:

root@hal:/sys/bus/i2c/devices/0-003e# echo 2700 > fan1_target 
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
2700
root@hal:/sys/bus/i2c/devices/0-003e# echo 1500 > fan1_target 
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
2433
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
2048
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
2048
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
1780
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
1780
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
1606
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
1606
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
1480
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
1480
root@hal:/sys/bus/i2c/devices/0-003e# cat fan1_input 
1507

As can be seen above, the speed progressively stabilizes to the expected value. If you are interested by a more useful setup, you can take a look at the section dedicated to automatic fan control based on NAS temperature using fancontrol package.

RICOH RS5C372A

The RTC of the system is provided by an I2C-connected Ricoh RS5C372A. Support for that chip is available in upstream kernel and is working fine.

NEC µPD720200 (D720200AF1)

The two USB3.0 ports on the rear of the NAS are provided by a NEC/RENESAS (Renesas bought NEC in 2010) µPD720200 USB 3.0 Host Controller, connected on PCIe bus. The configuration of the controller is provided by the ATMEL 512 Kilobit SPI flash.

Temperature sensor

Marvell 88F6282 SoC includes a temperature sensor. In Marvell 5.1.3 LSP (patches against linux 2.6.31.8 kernel on which NETGEAR kernel is based), a sensor driver is present to support the feature (/arch/arm/mach-feroceon-kw/hwmon.c, 189 lines). It provides a sysfs access to the temperature of the SoC.

It is nonetheless disabled in Netgear kernel (i.e. CONFIG_SENSORS_FEROCEON_KW is not set) and the userland on Duo v2 relies only on two other sensors to access the temperature on the enclosure: the ones included in the disks and available via smartctl.

I was about to port the drivers to 3.8 kernel when I noticed the submission of thermal sensor support for Kirkwood SoCs for upstream kernel by Nobuhiro Iwamatsu. Its set of patches has recently (2013-02-08) been applied to thermal -next tree. In the end, the patch should be availble in 3.9 kernel.

Once enabled (CONFIG_KIRKWOOD_THERMAL), the inclusion of kirkwood-6282.dtsi in NETGEAR readynas dts file, automatically provides the following information to describe how the SoC temperature sensor is supported (register, driver, status):

    thermal@10078 {
            compatible = "marvell,kirkwood-thermal";
            reg = <0x10078 0x4>;
            status = "okay";
    };

After a reboot on the new kernel, here is what is now available on the system:

root@hal:~# cd /sys/class/thermal/
root@hal:/sys/class/thermal# ls 
thermal_zone0
root@hal:/sys/class/thermal# cd thermal_zone0
root@hal:/sys/class/thermal/thermal_zone0# ls
passive  policy  subsystem  temp  type  uevent
root@hal:/sys/class/thermal/thermal_zone0# ls -l 
total 0
-rw-r--r-- 1 root root 4096 Feb 26 23:21 passive
-rw-r--r-- 1 root root 4096 Feb 26 23:21 policy
lrwxrwxrwx 1 root root    0 Feb 26 23:21 subsystem -> ../../../../class/thermal
-r--r--r-- 1 root root 4096 Feb 26 23:21 temp
-r--r--r-- 1 root root 4096 Feb 26 23:21 type
-rw-r--r-- 1 root root 4096 Feb 26 23:21 uevent

root@hal:/sys/class/thermal/thermal_zone0# cat type 
kirkwood_thermal

root@hal:/sys/class/thermal/thermal_zone0# cat temp 
28928

The final value provided by temp key is the SoC temperature in milli degrees Celsius (i.e. 28.928 °C). sensors command from lm-sensors package provides simple access to the value:

root@hal:~# sensors
g762-i2c-0-3e
Adapter: mv64xxx_i2c adapter
fan1:        2730 RPM  (div = 1)

kirkwood_thermal-virtual-0
Adapter: Virtual device
temp1:        +29.7°C

Marvell 88E1318

The SoC includes two Gigabit Ethernet MAC but no PHY. The gigabit PHY of the system is provided by a Marvell Alaska 88E1318.

Nuvoton 3012S

Local copy of Nuvoton NCT3012S datasheet .

Macronix MX25L512 512 Kilobit SPI Flash

The device has a Macronix MX25L512 512 Kilobit SPI flash chip. The chip is used to store the configuration of the XHCI controller. It is not connected to the SoC, i.e. cannot be read or modified by the system.

CR2032 Battery

The system includes a 3V CR2032 battery to maintain the system clock (Ricoh RSC5C32A) when the NAS is not connected on AC power.

Serial interface / Console

Marvell SoC directly embbeds two UARTs. In the NAS, one is rooted up to the second daughter board and associated pins are directly available at the rear of the device. Note that the serial port is a 3.3V one.

With a multimeter, it's easy to detect which pin on the board is TX, RX, GND and 3.3V VCC:

3.3V-capable USB-serial dongle

Once you have a proper access to the console (i.e. TX and RX working), you can see U-boot loading and interrupt it (3 second timeslot) to get access to U-boot console: 

XXXX FIXME XXXX include u-boot output

Some additional random notes on serial/console:

Richtek RT8105

Local copy of Richtek DS8105 datasheet. Local copy of Richtek RT8105 datasheet.

Texas Instruments - TPS65251

Local copy of TPS 65251 datasheet.

WINSTAR WH1602-TTI-JT 16x2 characters LCD module

Unlike the ReadyNAS Duo v2 but like the ReadyNAS 104, the ReadyNAS NV+ comes with a front 16x2 character LCD. More specifically, the device is a WINSTAR WH1602-TTI-JT. The device is usually controlled via 14 GPIO lines but it can also work in a 4-bit mode (instead of 8-bit mode), in which case, it consumes "only" 10. This is the mode used on the ReadyNAS NV+.

The rear side of LCD module is depicted below:

The LCD is connected to the main board via a 12 pins connectors.

LEDs and Buttons

Marvell Cryptograpic Engine and Security Accelerator (CESA)

Linux Kernel supports Marvell Cryptographic Engine and Security Accelerator (drivers/crypto/mv_cesa.{c,h}, commit 85a7f0ac). DT support has been recently added (see kirkwood.dtsi).

The hardware engine supports:

Nonetheless, at time of writing, current kernel code does not support DMA, and even thoug some initial discussions have taken place.

DMA/XOR engine

Marvell SoC such as Orion and Kirkwood support DMA XOR (and memcpy(), memset()) operations. Those can be useful to decrease CPU utilization in RAID setup. Here is the commit message associated with the introduction of the feature in Linux Kernel.

commit ff7b04796d9866327ea76e1393f1e902ef032f84
Author: Saeed Bishara <saeed@marvell.com>
Date:   Tue Jul 8 11:58:36 2008 -0700

    dmaengine: DMA engine driver for Marvell XOR engine
    
    The XOR engine found in Marvell's SoCs and system controllers
    provides XOR and DMA operation, iSCSI CRC32C calculation, memory
    initialization, and memory ECC error cleanup operation support.
    
    This driver implements the DMA engine API and supports the following
    capabilities:
    - memcpy
    - xor
    - memset
    
    The XOR engine can be used by DMA engine clients implemented in the
    kernel, one of those clients is the RAID module.  In that case, I
    observed 20% improvement in the raid5 write throughput, and 40%
    decrease in the CPU utilization when doing array construction, those
    results obtained on an 5182 running at 500Mhz.
    
    When enabling the NET DMA client, the performance decreased, so
    meanwhile it is recommended to keep this client off.
    
    Signed-off-by: Saeed Bishara <saeed@marvell.com>
    Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
    Signed-off-by: Nicolas Pitre <nico@marvell.com>
    Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

Note that the feature is also available for DT-converted SoC, as kikwood.dtsi file now has the required definition (since commit c896ed0f)

Kernel and system installation

XXX FIXME

Configuring custom actions for buttons

If you want to trigger custom actions using the power, backup and reset buttons, you can probably use this script as a basis.