|Network||2x 10/100/1000 Mbps|
|Sata||4x SATA II Marvell 88SX7042|
|USB 2.0||1x Front, 2x Back|
|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.
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
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:
mkfs.ext3 -I 128 /dev/sdx1