Device Specific Notes - 1000001101000/Debian_on_Buffalo GitHub Wiki
I'm still struggling with a good way to organize this information...
Devices with 64MB Memory (LS-XL, LS-CHLv2 and LS-WTGL)
The installer runs in a ram disk which requires ~20MB of memory and the install process itself requires another ~64MB of memory to run which results in devices with less that ~80MB of ram to need constant swap usage to operate the installer. With recent installer versions this eventually results in the installer locking up or crashing.
For these devices you can still use the "debootstrap" method to install debian.
Terastation III Devices (TS-XL, TS-RXL and TS-WXL)
These Devices are based on the MV78100 SoC which is supported by the Linux kernel but is not enabled by the kernel provided by Debian. They rely on a custom kernel which is configured to enable MV78100 support and patched to allow the Terastation's PCI SATA and RTC to work properly. These kernel packages are hosted in the /PPA directory of this project, the installer images handle setting up APT include this repository automatically.
Orion/MV78100 Devices using PCI SATA: Terastation II/III (TS-HTGL, TS-RHGL, TS-XL and TS-RXL)
These devices do not have "device-tree" support in the linux kernel and are affected by some minor issues regarding non-device-tree devices. Specifically the mv_sata driver will only work if compiled into the kernel rather than loaded as a module. I have made that change for the custom kernel which the install process uses for these devices.
All Terastations (except the TS1200D) and the Linkstation Pro (LS-GL)
These devices use an on-board microcontroller to manage some of their hardware functions. Generally, the older the devices is the more that is controlled by the microcontroller. Some of the things controlled by the microcontroller include:
- LEDs
- Buttons
- LCD Screen
- Fans
- Temperature Sensors
- Buzzer
- Power management
Part of the boot process for these devices includes the microcontroller waiting for a specific "boot_end" signal to indicate that the firmware booted successfully, otherwise the device reboots after a certain period of time which ranges from about 10 minutes for the older devices to ~4 hours on the TS3000 devices. The installer Includes a script that runs at boot and sends this signal.
Details of the protocol used to control the microcontroller can be found here:
https://buffalonas.miraheze.org/wiki/Terastation_Microcontroller_Interface
I've put together a Python library for interfacing with the microcontroller which includes examples:
https://github.com/1000001101000/Python_buffalo_libmicon
There's also a utility written in C that was used with the early Linkstations for the same purpose. I've created a fork which includes some fixes to allow it be used to set LCD messages (which is used within the installer):
https://github.com/1000001101000/micro-evtd
Rack-mounted Devices (TS-RHTGL, TS-RXL, TS1400R and TS3400R)
When the devices boot they set the fan to high speed which is extremely loud. I've added logic to the installer to lower them to medium during the installation (which is still pretty loud). The installer installs a "fan daemon" script which sets the fan speed via configurable temperature thresholds. see Post Installation Options
Shutdown/Restart behavior
Linkstation LS400 Series , V-Series (LS-VL/WVL/QVL) and likely other Kirkwood devices (LS-WXL etc)
These devices decide whether to power off or restart at shutdown based on the value of the wake-on-lan interrupt pin of the ethernet controller. In the stock firmware Buffalo used a special kernel driver to set the appropriate value when a shutdown is called. I've created a script which duplicates this behavior using a tool called phytool to set the appropriate values at shutdown/restart (see Tools/phy_restart.sh).
Linkstation LS200 Series
As far as I can tell the device decides whether to shutdown/restart based on the position of the "on/off" stitch on the back.
Terastation TS1400D/TS1400R
I still haven't been able to figure out how to completely shutdown these devices. Issuing a shutdown command causes the device to restart. If you issue a "halt" command the device the operating system will stop but the device remains on. I presume that the microcontroller can control this somehow, in part because the power button can power it off and seems to be only accessible via the microcontroller