HOWTO: Restore a ReadyNAS 102/104 to original state

This is a multipart procedure. Read it carefully and understand what is being done before attempting anything.

Direct links to the sections:

Introduction
The flash layout
Getting the original files
Flashing the kernel and ramdisk
Creating and writing the UBIFS image



Edited 3 time(s). Last edit at 07/29/2021 06:03AM by JF.

********************************************************************************
Marvell>> INTRODUCTION
********************************************************************************

This series of posts documents the procedure to restore a Netgear ReadyNAS 102/104 to its original manufacturing state.




Background

I have an RN102 on which I ran a stock Debian. Recently I needed to restore the device to its original state. That ended up being quite a bit of work, so I wrote those instructions to help anyone in the same situation.

After installing Debian on the NAS I needed to write the kernel and the initrd file (aka miniroot, aka ramdisk) to flash to boot Debian directly. As the initrd was too big to fit into the "minirootfs" MTD partition, containing ReadyNAS OS' initrd, I overwrote the "ubifs" partition. It was a dumb move but I didn't know any better at the time. Recreating the UBIFS was by far the most complex and time-consuming part of the process.

Before overwriting the "ubifs" partition I backed it up. I did that from Debian after installation, just before flashing the new kernel and initrd. But something went wrong and the resulting backup was seriously corrupt. I tried flashing it back, only to get endless errors and an unbootable system. Yet as damaged as it was I could still extract information from it on my PC, from which I figured out the UBIFS configuration and contents as expected by ReadyNAS OS.

Always do your backups kids, and always check that they're good before overwriting anything!




Disclaimers

IMPORTANT: this procedure is provided without any guarantee. You may kill your NAS, burn your house down, your dog may shit in your shoes, I won't be responsible for any of it. You're on your own. Good luck.

That said, I replayed it from the start (twice!) and I wrote down everything as I was validating it. The command lines and the outputs that you're seeing are exactly what I typed and what I got. It worked for me and should work for you too.

All the following commands were tested on a Debian 11 host and on a Netgear RN102 device. You may need to adapt them to your own setup.

The procedure should be reasonably safe on an RN104 too. AFAIK the hardware is identical, only with 2 more bays. The flash layout should be the same. OTOH I don't have any experience with the RN2xx generation, and I can't say if the procedure would work without having a look at an MTD dump first.

@Netgear: send me free hardware and I'll update my procedure. :)


I did the whole procedure without any drive in my NAS.

I put a wiped disk in after completing the procedure to make sure that everything works. It worked as expected: ReadyNAS OS started without any input and initialized the drive correctly.

I don't know what can happen after you restore your NAS and reboot it with non-empty drives in it. That all depends on ReadyNAS OS' behaviour, and has nothing to do with this procedure.




Assumptions

I'll assume that the "u-boot" and "u-boot-env" MTD partition on your NAS are undamaged. You NAS still boots, you can interrupt the boot process and get into the uBoot shell (the one that says "Marvell>>").

The three other MTD partitions, for the kernel, the initrd and the UBIFS, are expected to be damaged. We'll repair those three.

As such this is not a procedure for a full debricking, where your NAS can't even boot into uBoot. Maybe someone else has written or will write debricking instructions, after which you'll be able to jump to this one to complete the process.


I assume that you're somewhat familiar with general IT stuff, but not an expert. I have kept the whole procedure as simple as possible, with most of the steps happening directly in uBoot on the NAS. Read through it carefully, and if you feel overwhelmed or not sure, find someone to help you with it.




What can go wrong

Apart from the ReadyNAS-related issues mentioned previously, the worst that can happen is that you destroy the "u-boot" or "u-boot-env" MTD partitions. Then your NAS will be properly bricked. Otherwise you should be able to undo any mistake.

If you write over and over to your flash chip, you can wear out some cells. Those chips aren't top quality as they don't need to be: they're mostly read and rarely written. While the UBI layer provides some wear leveling, there's none in the other partitions. You can permanently damage your chip by rewriting the kernel or initrd over and over again.




Requirements

You will need:

• a Linux computer;
• the "mtd-utils" package (only for the UBIFS part);
• a working serial connection to your NAS;
• an empty USB stick, size <32GB, formatted in FAT32 / VFAT.

Before starting

Make sure that the serial connection to your NAS works reliably. Get familiar with the terminal software that you're using. Check that there aren't weird characters in the output or in what you type (which would indicate a link problem).

Before attempting anything, interrupt the boot process and fall into the uBoot shell. Then run at the very least the command "printenv", and copy-paste the output in a document somewhere.

********************************************************************************
Marvell>> THE FLASH LAYOUT
********************************************************************************


The ReadyNAS 10x NAS are equipped with a 128MiB flash chip that contains everything they need to get them started. They can't run directly from that chip as the data is heavily compressed. Instead at first boot with fresh drives they will create a root partition and filesystem, uncompress the data there, and on subsequent boots use this as the root FS.


The flash layout is as follows:

Marvell>> mtdparts
...
 #: name            size               offset            mask_flags
 0: u-boot          0x000000180000     0x000000000000    0
 1: u-boot-env      0x000000020000     0x000000180000    0
 2: uImage          0x000000600000     0x000000200000    0
 3: minirootfs      0x000000400000     0x000000800000    0
 4: ubifs           0x000007400000     0x000000c00000    0

The offset is the starting address in the flash chip, and the size is, well, the size. All in hexadecimal numbers of bytes.


In human-readable form:

 #: name            size
 0: u-boot          1.5 MiB
 1: u-boot-env      128 KiB
 2: uImage          6.0 MiB
 3: minirootfs      4.0 MiB
 4: ubifs           116 MiB

I know it doesn't add up to 128MiB exactly, but that's how things are.


Their roles are:

• "u-boot" contains the uBoot bootloader.
• "u-boot-env" contains the boot environment (what you see when you type "printenv").
• "uImage" contains the ReadyNAS OS kernel.
• "minirootfs" contains the ReadyNAS OS initrd.
• "ubifs" contains a UBIFS filesystem, which holds the compressed data that is needed to initialize the root FS on disk.

Through that procedure we'll overwrite the "uImage", "minirootfs" and "ubifs" contents, replacing them with the original ReadyNAS OS data.


On a side note, MTD means "Memory Technology Device". That's the generic name for all sorts of flash media. In uBoot the command to list the partitions is called "mtdparts". In Linux those partitions will appear under the name "/dev/mtdX". The X in "/dev/mtdX" matches the partition number in uBoot.

The partition name that uBoot reports is an arbitrary name that doesn't change anything. It's strictly for convenience, as it can be used in uBoot commands instead of the offset address.

********************************************************************************
Marvell>> GETTING THE ORIGINAL FILES
********************************************************************************


Download the ReadyNAS package for ARM from Netgear:
https://kb.netgear.com/20684/ReadyNAS-Downloads

This will give you a .zip file. At the time of writing the version is 6.10.5.


Unzip the file:

$ unzip ReadyNASOS-6.10.5-arm.zip 
Archive:  ReadyNASOS-6.10.5-arm.zip
  inflating: ReadyNASOS-6.10.5-arm.img  
  inflating: ReadyNASOS-6.10.5_Release_Notes.html

All the data that we need is inside that .img file. It's a tarball with a 16KiB header prepended.

The header contains only this, followed by all zeroes:

info::name=ReadyNASOS,version=6.10.5,time=1619067981,size=77307904,md5sum=0297d035d37792977d2f6b36dd53f31f,arch=arm,descr=ReadyNASOS

First get the tarball out of the .img file:

$ dd if=ReadyNASOS-6.10.5-arm.img of=ReadyNASOS-6.10.5-arm.tar bs=1024 skip=16
75480+0 records in
75480+0 records out
77291520 bytes (77 MB, 74 MiB) copied, 0.152685 s, 506 MB/s

Then create a directory to hold the data and extract it:

$ mkdir ReadyNASOS

$ tar -C ReadyNASOS -xvf ReadyNASOS-6.10.5-arm.tar 
csums.md5
initrd.gz
kernel
kernel.alpine
kernel.arm
root.tlz
u-boot-rn102-2.0.img
u-boot-rn104-2.0.img
u-boot-rn202-1.2.img
u-boot-rn204-1.2.img
u-boot-rn2120-2.0.img
u-boot-rn25-2.0.img

Both in the tarball and in the original UBIFS, "kernel" and "kernel.arm" are hardlinked (a single file that appears under two different names).

Check that everything is there, and look at the inode numbers on the left to make sure that "kernel" and "kernel.arm" have the same one, i.e. are hard links (your inode numbers will be different from mine):

$ ls -ahilp ReadyNASOS
total 78M
502 drwxr-xr-x  2 XXX  XXX   280 Jul 24 10:36 ./
  1 drwxrwxrwt 18 root root  520 Jul 24 10:36 ../
503 -rw-r--r--  1 XXX  XXX   551 Apr 22 07:16 csums.md5
504 -rw-r--r--  1 XXX  XXX  3.3M Apr 22 07:16 initrd.gz
505 -rw-r--r--  2 XXX  XXX  3.4M Apr 22 07:16 kernel
506 -rw-r--r--  1 XXX  XXX  3.3M Apr 22 07:16 kernel.alpine
505 -rw-r--r--  2 XXX  XXX  3.4M Apr 22 07:16 kernel.arm
507 -rw-r--r--  1 XXX  XXX   59M Apr 22 07:16 root.tlz
508 -rw-r--r--  1 XXX  XXX  872K Apr 22 07:16 u-boot-rn102-2.0.img
509 -rw-r--r--  1 XXX  XXX  874K Apr 22 07:16 u-boot-rn104-2.0.img
510 -rw-r--r--  1 XXX  XXX  1.1M Apr 22 07:16 u-boot-rn202-1.2.img
511 -rw-r--r--  1 XXX  XXX  1.1M Apr 22 07:16 u-boot-rn204-1.2.img
512 -rw-r--r--  1 XXX  XXX  972K Apr 22 07:16 u-boot-rn2120-2.0.img
513 -rw-r--r--  1 XXX  XXX  872K Apr 22 07:16 u-boot-rn25-2.0.img

Looking at the files, we can see:

• a kernel for the RN10x generation ("kernel" / "kernel.arm")
• a kernel for the RN2xx generation ("kernel.alpine")
• a common initrd
• u-boot images for each individual machine
• "root.tlz", which contains the files that will be written to the root partition on the hard drives.

Good news: everything we need is there. We have the kernel and the initrd. Importantly this is this also the exact contents of the original UBIFS, therefore we'll be able to recreate it.

********************************************************************************
Marvell>> FLASHING THE KERNEL AND RAMDISK
********************************************************************************


IMPORTANT WARNING

Raw flash has no wear leveling at all, nor CRC, nor overprovisioning, nor anything to help us with managing the life of the flash chip. We don't know how good the dies are, nor how much wear they already have. Therefore we need to avoid unneeded erase-write cycles.

DON'T OVERWRITE YOUR KERNEL AND INITRD PARTITIONS UNLESS YOU ABSOLUTELY HAVE TO!




Step 1: prepare the USB stick (on the PC)

Instead of TFTP and network loading, we'll use a USB stick to transfer data to the NAS.

If you're getting error messages or timeouts when loading from the USB stick on the NAS, use a different one. UBoot is picky.


Make sure that your USB stick is mounted. In the following examples mine is mounted on /media/sdb1.

The files we need are:

• the kernel for our machine;
• the initrd.

So:

$ cp -v ReadyNASOS/kernel ReadyNASOS/initrd.gz /media/sdb1/
'ReadyNASOS/kernel' -> '/media/sdb1/kernel'
'ReadyNASOS/initrd.gz' -> '/media/sdb1/initrd.gz'

Unmount your USB drive, and stick it into the USB 2.0 port of your NAS. It's the only one supported by uBoot. On the RN102 it's the one in front of the box.




Step 2: initialize the uBoot USB stack

Now on the NAS.

Have your serial console active. Power on your NAS and stop the autoboot. You'll get into the uBoot command line.

Mount the USB stick and check that everything is there:

Marvell>> usb start
(Re)start USB...
USB:   Active port:     0
Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found

Marvell>> usb tree

Device Tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Mass Storage (480 Mb/s, 100mA)
                USB Flash Memory 0611132321190

Marvell>> fatls usb 0:1
  3479896   kernel
  3427623   initrd.gz

2 file(s), 0 dir(s)

All good!




Step 3: wipe the partitions

Now check your mtd partition table, and wipe the kernel and initrd ones:

Marvell>> mtdparts

device nand0 <armada-nand>, # parts = 5
 #: name                size            offset          mask_flags
 0: u-boot              0x000000180000          0x000000000000          0
 1: u-boot-env          0x000000020000          0x000000180000          0
 2: uImage              0x000000600000          0x000000200000          0
 3: minirootfs          0x000000400000          0x000000800000          0
 4: ubifs               0x000007400000          0x000000c00000          0

active partition: nand0,0 - (u-boot) 0x000000180000 @ 0x000000000000

defaults:
mtdids  : none
mtdparts: none

Marvell>> nand erase uImage 0x000000600000

NAND erase: device 0 offset 0x200000, size 0x600000
Erasing at 0x7e0000 -- 100% complete.
OK

Marvell>> nand erase minirootfs 0x000000400000

NAND erase: device 0 offset 0x800000, size 0x400000
Erasing at 0xbe0000 -- 100% complete.
OK

Step 5: write the kernel and initrd

This is a multi-step process:

1. first initialize a memory buffer with 0xff (the empty flash value) of the same size as the destination partition;
2. load the file contents from the USB stick to that memory buffer;
3. write those contents to the partition;
4. re-read the contents to a different buffer;
5. and compare the contents of the two buffers.

It may seem overly complicated but there are good reasons for that:

• uBoot can't copy directly from USB to flash, we need to go through the RAM;
• using the full partition sizes avoids having to convert the file sizes to hex and the procedure stays generic;
• the 0xff pages in the source buffer won't actually be written to flash, thus minimizing wear (empty RAM pages would contain 0x00 and would be written to flash);
• raw flash chips don't have CRC or other mechanisms to detect corruption as in UBIFS, so at the very least we need to verify that we can read exactly what we wrote.

We'll use offset 0x2000000 (safe on those Marvell CPUs) as the source memory buffer base address.

We'll use offset 0x3000000 (safe too) as the compare memory buffer base address.


For the kernel:

Initialize the source buffer:

Marvell>> mw.b 0x2000000 0xff 0x000000600000

Load the kernel to the source buffer:

Marvell>> fatload usb 0:1 0x2000000 kernel
reading kernel

3479896 bytes read

Write the kernel to the mtd partition:

Marvell>> nand write.trimffs 0x2000000 uImage 0x000000600000

NAND write: device 0 offset 0x200000, size 0x600000
 6291456 bytes written: OK

Re-read what we just wrote into the compare buffer:

Marvell>> nand read 0x3000000 uImage 0x000000600000

NAND read: device 0 offset 0x200000, size 0x600000
 6291456 bytes read: OK

And check:

Marvell>> cmp.b 0x2000000 0x3000000 0x000000600000
Total of 6291456 bytes were the same

For the initrd:

Initialize the source buffer:

Marvell>> mw.b 0x2000000 0xff 0x000000400000

Load the initrd to the source buffer:

Marvell>> fatload usb 0:1 0x2000000 initrd.gz
reading initrd.gz

3427623 bytes read

Write the initrd to the mtd partition:

Marvell>> nand write.trimffs 0x2000000 minirootfs 0x000000400000

NAND write: device 0 offset 0x800000, size 0x400000
 4194304 bytes written: OK

Re-read what we just wrote into the compare buffer:

Marvell>> nand read 0x3000000 minirootfs 0x000000400000

NAND read: device 0 offset 0x800000, size 0x400000
 4194304 bytes read: OK

And check:

Marvell>> cmp.b 0x2000000 0x3000000 0x000000400000
Total of 4194304 bytes were the same

Done!

********************************************************************************
Marvell>> CREATING AND WRITING THE UBIFS IMAGE
********************************************************************************


IMPORTANT WARNING

Each UBI block contains that block's total erase count since manufacturing. This information is essential for the correct operations of UBI's wear leveling algorithm. Wiping the partition clean and recreating UBI/UBIFS will start again with a blank sheet, losing all previous erase count information. That can lead later to higher wear blocks on the chip, and a reduced lifespan. UBI will be able to work around bad blocks to some extent, but the smarter move is to keep the original erase counts.

DON'T OVERWRITE YOUR UBIFS PARTITION UNLESS YOU ABSOLUTELY HAVE TO!




Introduction to UBI and UBIFS

UBI and UBIFS are strange beasts for anyone unfamiliar with the embedded world.

From Wikipedia:

Quote

UBI (Unsorted Block Images) is an erase block management layer for flash memory devices. UBI serves two purposes, tracking NAND flash bad blocks and providing wear leveling.

In other words, the UBI layer manages the flash chip at the lowest level. It doesn't care about files, directories, permissions or anything like that. It tracks erase block and write page usage, keeps a mapping of logical to physical pages to work around bad blocks, etc. It provides a minimal abstraction to the next layer up, UBIFS, so that it doesn't have to worry about the gory details.

UBIFS is the filesystem layer. It behaves essentially like what we'd expect from a normal filesystem, except for one important detail. On non-embedded systems, standards like AHCI or NVMe define many things such as how to ask a drive for its block size. And that block size it itself effectively standardized to be either 512 bytes or 4K. Internally the drives have wildly different erase and page sizes, that are orders of magnitude larger than the logical pages that the OS knows about. A piece of the drive firmware, called the FTL (Flash Translation Layer), does the mapping and management of logical blocks. By providing this abstraction all drives appear identical and all filesystems work happily.

There's no such thing with UBIFS. The page and block sizes of UBIFS are the erase block and programming page sizes from the specific flash chip that you're using. It makes sense: you neither need nor want compatibility-oriented abstraction layers when you're deeply embedded. But the inconvenience is that you need to obtain some information from your chip before creating an UBIFS image.


On those ReadyNAS devices, I reckon that the UBI initialization is done individually on each device during manufacturing. My own flash chip has bad blocks in that range, yet UBIFS avoided them entirely. Not as in "I detected a bad block and I'm not using it", but as in "the entire UBI volume was (size of the partition) minus (size of the bad blocks)". That means that they existed before the UBI volume initialization, which in turn implies that this wasn't a standard image but was custom for that chip.




The UBI / UBIFS on-disk layout

A partition used for UBI contains or one or more volumes, which in turn contain UBIFS images (filesystems). Volumes are similar to simple LVM volumes (they can even be resized).

An UBI partition or volume is composed of blocks called PEB, or Physical Erase Blocks. As their name implies, those data blocks have the same size as the underlying flash chip erase blocks. Each PEB contains some header bytes (erase count and volume information), and then data. That means that the amount of data available to UBIFS is less than the size of the PEB. Enters the LEB size, or Logical Erase Block size: that's how much data UBIFS can store in each PEB.

To create an UBIFS image, one needs to know a few things. The LEB size, ultimately derived from the chip specs, is one. Then there is the minimum IO or write page size, also a chip spec. (Flash bytes cannot be written individually, but only in fixed-size blocks called write pages.) And finally we need to know how big the volume is -- that is, how many PEBs/LEBs there are.


On the ReadyNAS 10x, the UBI partition contains one single dynamic (read-write) volume called "rootfs" (important!), taking up the full space of the partition. So that's the setup that we will reproduce.




uBoot limitations

Linux has no problem accessing an UBIFS partition and reading from and writing files to it. But at least in the uBoot that ships on those NAS, there isn't any file-level write capability.

This uBoot can:

• initialize UBI on a partition;
• create and delete volumes on that partition;
• read or write an entire UBIFS image from or to a volume;
• mount / umount a volume;
• list files in a mounted volume and read a file to memory.

Essentially it has just enough UBIFS support to boot from files in an UBIFS volume, but not enough to, say, copy files from USB to UBIFS.

As a result, we need to create an entire UBIFS image (a prepared filesystem image, like you would prepare an ISO image before burning it to CD) on the computer, then write it whole to the volume.


This will require a back-and-forth between the NAS and the computer: first initialize UBI to get the configuration details we need, then create the image on the computer, then back to the NAS to write it.




Step 1: initialize the UBI partition

If not already done: start your serial console, power on your NAS, interrupt the boot and get to the UBoot console.

Wipe the "ubifs" partition:

Marvell>> nand erase ubifs 0x000007400000

NAND erase: device 0 offset 0xc00000, size 0x7400000
Skipping bad block at  0x07f00000
Skipping bad block at  0x07f20000
Skipping bad block at  0x07f40000
Skipping bad block at  0x07f60000
Skipping bad block at  0x07f80000
Skipping bad block at  0x07fa0000
Skipping bad block at  0x07fc0000
Skipping bad block at  0x07fe0000

OK

As you can see I have bad blocks on my chip. You may have too -- or not. YMMV.


Inialize UBI on the partition:

Marvell>> ubi part ubifs
Creating 1 MTD partitions on "nand0":
0x000000c00000-0x000008000000 : "mtd=4"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes               <---
UBI: smallest flash I/O unit:    2048                       <---
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI: create volume table (copy #2)
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=4"
UBI: MTD device size:            116 MiB
UBI: number of good PEBs:        920
UBI: number of bad PEBs:         8
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             907                        <---
UBI: total number of reserved PEBs: 13
UBI: number of PEBs reserved for bad PEB handling: 9
UBI: max/mean erase counter: 1/0

Then create one UBI volume with the right name, and check the resulting layout:

Marvell>> ubi createvol rootfs
No size specified -> Using max size (115167232)
Creating dynamic volume rootfs of size 115167232

Marvell>> ubi info l
UBI: volume information dump:
UBI: vol_id          0
UBI: reserved_pebs   907
UBI: alignment       1
UBI: data_pad        0
UBI: vol_type        3
UBI: name_len        6
UBI: usable_leb_size 126976
UBI: used_ebs        907
UBI: used_bytes      115167232
UBI: last_eb_bytes   126976
UBI: corrupted       0
UBI: upd_marker      0
UBI: name            rootfs

UBI: volume information dump:
UBI: vol_id          2147479551
UBI: reserved_pebs   2
UBI: alignment       1
UBI: data_pad        0
UBI: vol_type        3
UBI: name_len        13
UBI: usable_leb_size 126976
UBI: used_ebs        2
UBI: used_bytes      253952
UBI: last_eb_bytes   2
UBI: corrupted       0
UBI: upd_marker      0
UBI: name            layout volume

From those outputs we can gather all the information that we need. I have added arrows to mark the location of the numbers in the outputs above.

For that chip:

• the LEB size is 126976
• the minimum IO size (write page size) is 2048
• the number of PEBs/LEBs is 907

Remember that this depends on your flash chip, and your values may be different!




Step 2: create the UBIFS image

Back on the computer, create the UBIFS image with the values that you just obtained:

$ /usr/sbin/mkfs.ubifs --leb-size=126976 --min-io-size=2048 --max-leb-cnt=907 --verbose --space-fixup --squash-uids --root=ReadyNASOS --output=ReadyNASOS.ubifs
mkfs.ubifs
    root:         ReadyNASOS/
    min_io_size:  2048
    leb_size:     126976
    max_leb_cnt:  907
    output:       ReadyNASOS.ubifs
    jrn_size:     8388608
    reserved:     0
    compr:        lzo
    keyhash:      r5
    fanout:       8
    orph_lebs:    1
    space_fixup:  1
    selinux file: (null)
    super lebs:   1
    master lebs:  2
    log_lebs:     5
    lpt_lebs:     2
    orph_lebs:    1
    main_lebs:    611
    gc lebs:      1
    index lebs:   5
    leb_cnt:      622
    UUID:         0B7371B4-F33E-42F8-BB9B-EDD7BAA8B874
Success!

If you have ubidump installed you can check the contents of the .ubifs file:

$  ubidump -l ReadyNASOS.ubifs
==> ReadyNASOS.ubifs <==
-rw-r--r--  1 0     0        3427623 2021-04-22 05:16:56 initrd.gz
-rw-r--r--  1 0     0        3448616 2021-04-22 05:16:56 kernel.alpine
-rw-r--r--  1 0     0        1147028 2021-04-22 05:16:56 u-boot-rn202-1.2.img
-rw-r--r--  2 0     0        3479896 2021-04-22 05:16:56 kernel
-rw-r--r--  1 0     0       60950986 2021-04-22 05:16:48 root.tlz
-rw-r--r--  2 0     0        3479896 2021-04-22 05:16:56 kernel.arm
-rw-r--r--  1 0     0            551 2021-04-22 05:16:56 csums.md5
-rw-r--r--  1 0     0         995112 2021-04-22 05:16:56 u-boot-rn2120-2.0.img
-rw-r--r--  1 0     0         894280 2021-04-22 05:16:56 u-boot-rn104-2.0.img
-rw-r--r--  1 0     0         892032 2021-04-22 05:16:56 u-boot-rn25-2.0.img
-rw-r--r--  1 0     0        1146748 2021-04-22 05:16:56 u-boot-rn204-1.2.img
-rw-r--r--  1 0     0         892696 2021-04-22 05:16:56 u-boot-rn102-2.0.img

2 instead of 1 for "kernel" and "kernel.arm" and the two files are the same size (for the hardlink), and "0 0" (root) for the owner and group. Looks good.

Then copy the .ubifs file to your USB stick.




Step 3: calculate the image size in hexadecimal

We'll need the file size in hexadecimal in uBoot, so while we're on the computer we can get it easily:

$ printf "0x%x\n" $(stat -c "%s" ReadyNASOS.ubifs)
0x4b52000

This size depends on the parameters that were used, and yours is very likely to be different!




Step 4: (re)initialize the uBoot USB stack

Now on the NAS.

After plugging in your stick you have to restart the USB stack. This needs to be done every time there's a change (no hotplug support).

Mount the USB stick and check that everything is there:

Marvell>> usb start
(Re)start USB...
USB:   Active port:     0
Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found

Marvell>> usb tree

Device Tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Mass Storage (480 Mb/s, 100mA)
                USB Flash Memory 0611132321190

Marvell>> fatls usb 0:1
  3479896   kernel
  3427623   initrd.gz
 78979072   readynasos.ubifs

3 file(s), 0 dir(s)

All good!




Step 5: load the image to memory and write it to flash

Note: if you restarted the NAS since you created the UBI volume, you need to reattach the UBI partition first by running "ubi part ubifs" again.

Just like with the kernel and initrd, we need to copy to RAM first, then write to disk. Due to the peculiarities of UBIFS we have to write the exact image size (that's why we got the file size in hex earlier).


Load the UBIFS image into RAM:

Marvell>> fatload usb 0:1 0x2000000 readynasos.ubifs
reading readynasos.ubifs

78979072 bytes read

That will take a while, it's a large file.


Using your file size in hex in the last position, write the UBIFS image to flash:

Marvell>> ubi writevol 0x2000000 rootfs 0x4B52000
78979072 bytes written to volume rootfs

Step 6: check what we wrote

Check that we can mount the UBIFS and list its contents:

Marvell>> ubifsmount rootfs
UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: mounted read-only
UBIFS: file system size:   113770496 bytes (111104 KiB, 108 MiB, 896 LEBs)
UBIFS: journal size:       9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root:  0 bytes (0 KiB)

Marvell>> ubifsls
          3427623  Thu Apr 22 05:16:56 2021  initrd.gz
          3448616  Thu Apr 22 05:16:56 2021  kernel.alpine
          1147028  Thu Apr 22 05:16:56 2021  u-boot-rn202-1.2.img
          3479896  Thu Apr 22 05:16:56 2021  kernel
         60950986  Thu Apr 22 05:16:48 2021  root.tlz
          3479896  Thu Apr 22 05:16:56 2021  kernel.arm
              551  Thu Apr 22 05:16:56 2021  csums.md5
           995112  Thu Apr 22 05:16:56 2021  u-boot-rn2120-2.0.img
           894280  Thu Apr 22 05:16:56 2021  u-boot-rn104-2.0.img
           892032  Thu Apr 22 05:16:56 2021  u-boot-rn25-2.0.img
          1146748  Thu Apr 22 05:16:56 2021  u-boot-rn204-1.2.img
           892696  Thu Apr 22 05:16:56 2021  u-boot-rn102-2.0.img

Great!

Umount the UBIFS volume:

Marvell>> ubifsumount
Unmounting UBIFS volume rootfs!

Step 7: reboot

Check that your env is correct:

Marvell>> printenv bootargs
bootargs=console=ttyS0,115200

Marvell>> printenv bootcmd
bootcmd=nand read 0x2000000 0x200000 0x600000; nand read 0x3000000 0x800000 0x400000; bootm 0x2000000 0x3000000 0x1000000

Marvell>> printenv mtdparts
mtdparts=mtdparts=armada-nand:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs)

I guess that it should look the same on RN104 too.

If everything is alright, reboot:

Marvell>> reset
resetting ...

After the NAS resets and reboots under Linux, you'll see something like this on the serial console:

Starting the boot process...
Detected system type: RN102
Loading kernel modules...done
Boot mode: Normal
UBI device number 0, total 920 LEBs (116817920 bytes, 111.4 MiB), available 9 LEBs (1142784 bytes, 1.1 MiB), LEB size 126976 bytes (124.0 KiB)

The boot process will hang there for a little bit as the UBIFS free space is fixed on first boot, and then continue. It's alright. Don't panic.



Edited 1 time(s). Last edit at 07/29/2021 06:03AM by JF.

And that's it! Good luck everyone!

JF,

I finally sat down and read it slowly. That was a great tutorial :)

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