Terastation TS-RXL

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 serial port on the front of the device outputs the devices console output which can be used for troubleshooting. The port has input disabled.

It is supposed to be possible to re-enable input on the serial port by removing a chip from the pcb (I have not yet tried this). see: Terastation III Serial console (Buffalo NAS Central)

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: mkfs.ext3 -I 128 /dev/sdx1

Buffalo Resources

 * Product Description
 * Manuals, Firmware, etc