Terastation TS-RXL

Specs

CPU	800MHz
Memory	512MB
Bays	4
Network	2x 10/100/1000 Mbps
Sata	4x SATA II Marvell 88SX7042
NAND Flash	512MB
SPI Flash
USB 2.0	1x Front, 2x Back
Fan	Yes
Power	Internal AC 100-240V, universal 50/60Hz

Stock Firmware Installation

Install Firmware from NAND

If blank drives are inserted the device will boot from it's internal NAND and eventually go into EM mode. Once the device is in EM mode the firmware can be installed using tsupdater in debug mode, see Enable Debug mode for LSUpdater/TSUpdater.

Other Methods

This device is much less flexible about what partitions/filesystems it will attempt to boot from. I recommend installing from NAND so that the device will build appropriate partitions for you. It is possible to install via TFTP or loading files directly if desired.

Custom Firmware/Operating System installation

See Installing Debian on MV78100 Devices (TS-WXL, TS-XL,TS-RXL)

Device Notes

The headphone jack on the front appears to be a serial console, I have not yet tried using it.

Although it's possible to change uboot environment variables from within the stock firmware, changing the bootcmd does not seem to affect the boot process for some reason. I attempted to change the location that uboot loads the initrd image and confirmed the change persisted through a reboot but the console output shows that it still loads from the default address. see below for a workaround.

U-boot max file sizes

The stock U-boot will crash if you try to load a kernel image larger than (somewhere between 4-6MB, still looking for actual limit).

The stock U-boot loads the initrd after the kernel but earlier in memory. this means that if the initrd is larger than 23mb it will overlap the kernel. If you create an initrd uboot image with 23mb of padding at the beginning followed by a copy of the kernel (to re-write it in the proper location) you can then append a larger initrd image (provided you hardcode the new offset into your kernel's cmdline).

Partition table notes

The stock firmware partitions the disks using GPT partition tables. It writes the MAC address of eth0 to 0x28 of the beginning of the disk when formatting a disk, it then checks this at boot time to determine whether the disk is "owned" by this device. The boot loader does not seem to do anything differently if this doesn't match or is missing but I have not tested it extensively.

00000000  01 00 00 00 00 00 00 00  20 00 00 00 00 00 00 00  |........ .......|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  30 30 3a 31 64 3a 37 33  |........00:1d:73|
00000030  3a 66 66 3a 34 66 3a 66  62 00 00 00 00 00 00 00  |:ff:4f:fb.......|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

boot partition requirements

The boot files are loaded using u-boot's ext2load function with hardcoded parameters. To boot successfully the boot partition must be:

the first partition on the disk
either a regular partition or part of a raid1 array using metadata version 0.9
formatted using the ext2 or ext3 filesystem
have an inode size of 128 bytes (newer distros have started using 256 as the default)
relatively small, 1GB is usually more than enough for /boot (I have not yet experimented to determine the max allowable size)

The filesystem can be created with: