Installing Debian Jessie on a Netgear ReadyNAS 102
The procedure for installing Debian Jessie on the ReadyNas 102 is very similar to that detailed by Uwe Kleine-Koenig for the ReadyNas 104. There are a few subtle differences, which I document here.
I’m greatly indebted to Uwe and Martin Michlmayr, who patiently guided me through the hairier bits.
__ __ _ _
| \/ | __ _ _ ____ _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| | | | (_| | | \ V / __/ | |
|_| |_|\__,_|_| \_/ \___|_|_|
_ _ ____ _
| | | | | __ ) ___ ___ | |_
| | | |___| _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
\___/ |____/ \___/ \___/ \__|
Summary
This procedure requires two hosts. One is the RN102, the other is a (Debian) Linux host (workstation). The latter is used to prepare everything to install Debian Jessie on the former.
On the workstation, the procedure first tweaks the Debian installer so it will run on the RN102. On the RN102 we then load this installer using FTP, accessing it from the RN102 boot loader shell. Next, we complete the installation, and copy a spare kernel to the workstation, just in case. Lastly, we save the Debian kernel to the NAND device.
Preliminaries
First, get familiar with the boot loader, U-Boot.
To access the RN102’s Marvell U-Boot shell, remove the tiny grey sticker to the left of the Ethernet jack, and connect a serial cable to the UART pins. You only need the gnd (usually black) and RX (white) and TX (green).
Plug the other end, the USB connector, in your Debian workstation, and in a term, do:
screen -L /dev/ttyUSB0 115200
Used this way, screen will save everything it shows to screenlog.0. This is recommended, in case you need to share output with others.
An alternative for screen is grabserial.
grabserial -d /dev/ttyUSB0 -o /path/to/outputfile
Power on
Power on the RN102. If screen or grabserial on the workstation show gibberish, unplug the USB connector, and restart screen and or grabserial. It might take a handful of tries, NAS reboots and combinations of screen and grabserial together in separate terms, before you get legible output.
The two RN102 devices I toyed with, ran:
U-Boot 2009.08 (Jun 03 2013 - 09:07:26)Marvell version: 1.1.2 NQ
and
Linux-3.0.101.RN_ARM.4 (2015-06-30)
On the workstation, you can access the ReadyNas web management interface via a browser. It allows you to update the firmware. Result:
U-Boot 2011.12-gec25d27-dirty (Oct 26 2015 - 16:53:05) Marvell version: v2011.12 2014_T2.0p1
and:
Linux-4.1.13.armada.1 (2015-11-21)
Keeping screen on all this while, you will by now recognise the booting process of the RN102. So you will know when to hit the any key, or rather, the ‘any-but-the-function-keys’ key, at the right moment:
Hit any key to stop autoboot:
After which you will see the U-Boot prompt:
Marvell>>
Making the installer
On your workstation, you now need to make the Debian installer. The steps are identical to those described by Uwe, except for the third one, You need:
The current Device Tree Blob for the RN102 is subtly different from the dtb on the RN012 I worked on, but it is close enough for the installer and Debian installation.
To make the installer, do like Uwe does, except that you adapt the recipe to the RN102.
# apt-get install u-boot-tools
$ cat vmlinuz armada-370-netgear-rn102.dtb > vmlinuz-rn102
$ mkimage -A arm -O linux -T multi -C none -a 0x04000000 -e 0x04000000 -n "Debian Jessie armhf installer" -d vmlinuz-rn102:initrd.gz uImage-installer-rn102
# cp uImage-installer-rn102 /srv/tftp
Copy the uImage-installer-rn102 to the ftp server. No FTP server yet?
# apt install tftpd
Now copy uImage-installer-rn102 to /srv/tftp
Loading the installer
Switch to screen, showing the RN102. At the Marvell» U-Boot prompt, type:
dhcp
setenv serverip 192.168.1.4
tftp uImage-installer-rn102
bootm $load_addr
Where, of course, 192.168.1.4 is the IP address of the tftp host. In my case, it is the workstation.
The Debian installer will boot, and you can go through the usual steps to complete the installation. Don’t worry if there is no way to mark any of the partitions as bootable.
Warning
The final step in the Debian installation will prompt you to hit and reboot. Don’t do that. Instead, hit and in the Debian installation menu scroll down to the “Execute a shell” option.
In the shell, enter the following:
mount --bind /dev /target/dev
mount -t proc none /target/proc
mount -t sysfs none /target/sys
chroot /target /bin/sh
apt-install flash-kernel
You next need to adapt /etc/flash-kernel/db
vi /etc/flash-kernel/db
and enter this:
Machine: NETGEAR ReadyNAS 102
DTB-Id: armada-370-netgear-rn102.dtb
DTB-Append: yes
Mtd-Kernel: uImage
Mtd-Initrd: minirootfs
U-Boot-Kernel-Address: 0x04000000
U-Boot-Initrd-Address: 0x0
Required-Packages: u-boot-tools
Bootloader-Sets-Incorrect-Root: yes
You can (but don’t have to) make two more changes.
In /etc/initramfs-tools/initramfs.conf, set:
MODULES=dep
and in /etc/initramfs-tools/conf.d/compress set:
COMPRESS=xz
After this, you can run
# update-initramfs -u
And if all goes well you will see something like:
update-initramfs: Generating /boot/initrd.img-3.16.0-4-armmp
DTB: armada-370-netgear-rn102.dtb
Installing armada-370-netgear-rn102.dtb into /boot/dtbs/3.16.0-4-armmp/armada-370-netgear-rn102.dtb
Installing new armada-370-netgear-rn102.dtb.
Installing armada-370-netgear-rn102.dtb into /boot/dtbs/3.16.0-4-armmp/armada-370-netgear-rn102.dtb
Taking backup of armada-370-netgear-rn102.dtb.
Installing new armada-370-netgear-rn102.dtb.
flash-kernel: installing version 3.16.0-4-armmp
flash-kernel: appending /usr/lib/linux-image-3.16.0-4-armmp/armada-370-netgear-rn102.dtb to kernel
Generating kernel u-boot image... done.
Flashing kernel (using 3194733/6291456 bytes)
done.
Sidestep
Now, please get the UUID for the / partition, by looking at /etc/fstab
Just in case you run into trouble, the next steps help make a copy of the Linux kernel installed on the NAND. This copy you can access via FTP like you did the installer.
In screen, accessing the RN102, your newly created Debian host, do:
$ scp /boot/vmlinuz you@workstation
$ scp /boot/initrd.img you@workstation
On the workstation, and in the location where you scp’ed vmlinuz and initrd.img, do:
$ cat vmlinuz armada-370-netgear-rn102.dtb > vmlinuz-rn102
$ mkimage -A arm -O linux -T multi -C none -a 0x4000000 -e 0x4000000 -n "Debian Jessie armhf rn201" -d vmlinuz-rn102:initrd.img uImage-rn102
On the workstation, copy uImage-rn102 to /srv/tftp .
In case of trouble, you can load this kernel using:
dhcp
setenv serverip 192.168.1.4
tftp uImage-rn102
bootm $load_addr
Reboot
We’re almost done. For the last step, you have to interrupt the start-up, to write the boot procedure to the NAND. First test the recipe, and if that succeeds, store it. So you need to reboot. Twice.
The first time, at the Marvell» prompt, do:
setenv bootargs $console
root=UUID=12345678-ottf-1234-123a-12345ab123ab
nand read 0x2000000 0x200000 0x600000
nand read 0x3000000 0x800000 0x400000
bootm 0x2000000 0x3000000
Where the UUID number is what you recorded by looking at /etc/fstab Actually, this should work even without the root=UUID= line.
Some explanation
The syntax for nand read is:
nand read $address_in_ram $offset_in_nand $count_of_bytes
According to the RN102’s device tree, the uImage partition starts at 0x200000 and has a size of 0x600000. Hence
nand read 0x2000000 0x200000 0x600000
and not
nand read 0x2000000 0x200000 0x400000
In the latter case, you get a boot failure once the kernel gets bigger than 4 MB. Flash-Kernel will not detect that because the partition is 6 MB big.
If this works, reboot and, again, interrupt the start-up.
At the Marvell» prompt, do:
setenv bootcmd 'nand read 0x2000000 0x200000 0x600000; nand read 0x3000000 0x800000 0x400000; bootm 0x2000000 0x3000000'
saveenv
You’ll see:
Saving Environment to NAND...
Erasing Nand...
Writing to Nand... done
Now you’re done.
Bad blocks
If your RN102 shows bad blocks like this:
NAND: (ID 0xf1ad) 128 MiB
MMC: MRVL_MMC: 0
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x000000240000
and if your update-initramfs -u is followed by:
nand: nand_erase_nand: attempt to erase a bad block at page 0x00000480
mtdblock: erase of region [0x40000, 0x20000] on "uImage" failed
and lots of these:
end_request: I/O error, dev mtdblock2, sector 3496
Buffer I/O error on device mtdblock2, logical block 437
lost page write due to I/O error on mtdblock2
Then you need to proceed with care. See Debian Bug#813995. It is possible that “update-initramfs -u” will not correctly write an image to the NAND. You probably should not write to NAND at all in case of bad blocks, until this bug is fixed.
Very useful links
Gijs Hillenius
Context for Digital Government
Policy specialist on open source in public services, knowlegde transfer expert