Differences

This shows you the differences between two versions of the page.

--- doc:appunti:hardware:qnap_ts-120 [2022/02/10 22:34] – [Upgrading to 4 Tb Hard Disk] niccolo
+++ doc:appunti:hardware:qnap_ts-120 [2025/04/01 12:55] (current) – [Cooling Fan] niccolo
@@ Line 95: / Line 95: @@
 </code>
-===== Console seriale =====
+===== The Serial Console =====
-Vedere qui: [[http://www.cyrius.com/debian/kirkwood/qnap/ts-119/serial/]]
+{{ .:qnap:qnap-ts-120-serial-console-jtag.jpg?direct&400|QNAP TS-120: Console connector}}
+{{ .:qnap:qnap-ts-120-serial-console-closeup.jpg?direct&160|Serial Console JTAG Connector}}
+On the circuit board of the QNAP TS-120 there is a JTAG connector for the serial console. I used an old CD-ROM audio cable because it had the right connector. I wired only the **GND**, **TX** and **RX** pins from to QNAP to a serial-to-USB adapter. The adapter was inserted intp a GNU/Linux computer running the **minicom** program. The speed of the serial line was set to **115200**. The connector pinout is documented in this page: [[http://www.cyrius.com/debian/kirkwood/qnap/ts-119/serial/|Serial console for QNAP TS-11x/TS-12x]].
-===== Tips =====
+^ Console Pinout  ^^
+^ 1  | TX        |
+^ 2  | VCC +3.3  |
+^ 3  | RX        |
+^ 4  | GND       |
+This is the boot process captured from the serial line. At the end of the bootstrap you will get a **login prompt**.
+<code>
+         __  __                      _ _
+        |  \/  | __ _ _ ____   _____| | |
+        | |\/| |/ _` | '__\ \ / / _ \ | |
+        | |  | | (_| | |   \ V /  __/ | |
+        |_|  |_|\__,_|_|    \_/ \___|_|_|
+ _   _     ____              _
+| | | |   | __ )  ___   ___ | |_
+| | | |___|  _ \ / _ \ / _ \| __|
+| |_| |___| |_) | (_) | (_) | |_
+ \___/    |____/ \___/ \___/ \__|  ** LOADER **
+ ** MARVELL BOARD: DB-88F6282A-BP LE TS-120 ,PHY=1.8v
+U-Boot 1.1.4 (Nov  5 2012 - 17:39:47) Marvell version: 3.5.3
+U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CD5C0
+Soc: MV88F6282 Rev 1CPU running @ 1600Mhz L2 running @ 533Mhz
+SysClock = 533Mhz , TClock = 200Mhz
+</code>
+===== Real Time Clock rtc0 =====
+Into the QNAP TS-120 there is a Real Time Clock. You can see the battery on the motherboard and the kernel will print this on the serial console:
+<code>
+[    1.262622] hctosys: unable to open rtc device (rtc0)
+[    1.628724] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0
+</code>
+The problem is that kernel packages **%%linux-image-4.19.0-*-marvell%%** include the RTC driver **compiled as a module** and the kernel executes **hctosys** before the module is loaded, so before the **rtc0** device is available. When the **rtc0** device becomes available, the **udev** subsystem is triggered by the file **/usr/lib/udev/rules.d/85-hwclock.rules**. The rule says to run the script **/usr/lib/udev/hwclock-set**.
+Historically that script does nothing if **systemd** is running, because it assumes that the system clock was already set from the hardware clock. See Debian bug **[[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203|#855203 - hwclock-set: Synchronize from hwclock despite systemd presence]]**.
+A quick and dirty solution is to edit the script **/lib/udev/hwclock-set** removing the systemd check:
+<code>
+#if [ -e /run/systemd/system ] ; then
+#    exit 0
+#fi
+</code>
+You should also comment-out the **hwclock** commands containing the **%%--systz%%** option, (from the man page: "//It is intended to be used in a startup script on systems with kernels above version 2.6 where you know the System Clock has been set from the Hardware Clock by the kernel during boot//"):
+<code>
+  #/sbin/hwclock --rtc=$dev --systz --badyear
+...
+  #/sbin/hwclock --rtc=$dev --systz
+</code>
+===== Problem with the I2C bus locked =====
+Booting the **4.9.0-17** kernel, the ''dmesg'' output reveals the following error message:
+<code>
+i2c /dev entries driver
+i2c i2c-0: mv64xxx_i2c_fsm: Ctlr Error -- state: 0x7, status: 0x38, addr: 0x30, flags: 0x1
+rtc-s35390a 0-0030: error resetting chip
+rtc-s35390a: probe of 0-0030 failed with error -5
+</code>
+Booting the **4.19.0-21** kernel, the error message is slightly different:
+<code>
+i2c /dev entries driver
+i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
+rtc-s35390a 0-0030: error resetting chip
+rtc-s35390a: probe of 0-0030 failed with error -5
+</code>
+This means that the I2C bus is locked and the RTC kernel module cannot load properly:
+<code>
+modprobe rtc-s35390a
+</code>
+again we can read the ''dmesg'' output:
+<code>
+i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
+rtc-s35390a 0-0030: error resetting chip
+rtc-s35390a: probe of 0-0030 failed with error -5
+</code>
+The **problem was solved** by powering off the QNAP, **unplugging the power** connector and removing the inside clock battery (this last operation may be not necessary).
+If the module is loaded and working, you can read the pseudofile **/proc/driver/rtc**:
+<code>
+cat /proc/driver/rtc
+rtc_time        : 12:55:51
+rtc_date        : 2025-03-31
+alrm_time       : 12:50:51
+alrm_date       : 2025-04-01
+alarm_IRQ       : no
+alrm_pending    : no
+update IRQ enabled      : no
+periodic IRQ enabled    : no
+periodic IRQ frequency  : 1
+max user IRQ frequency  : 64
+hr            : yes
+</code>
+**NOTICE**: There is a problem with poweroff which results into a reboot, which is eventually related to the RTC, which is working on the I2C bus. See the following thread for some insight: **[[https://groups.google.com/g/linux.debian.ports.arm/c/Vb-uE7Emj_k|Debian Jessie on QNAP TS-112P - Reboot instead of shutdown]]**. Check also the **qcontrol** tool, which does have an **rtc on** option.
-  * FIXME C'è un clock RTC a bordo?
 ===== Upgrading to 4 Tb Hard Disk =====
@@ Line 116: / Line 227: @@
 </code>
-==== Dump and restore ====
+==== Partition, dump and restore ====
-To avoid a complete reinstallation, I performed a dump/restore via SSH.
+To avoid a complete reinstall, I **connected the new disk to a GNU/Linux computer**, then partitioned the disk and performed a dump/restore via SSH.
-==== Keel the UUID of root filesystem ====
+For partitioning I used **parted**, see above for the partition schema. I created the ext4 filesystem and performed a dump/restore over the net, using SSH:
-Beware that the **kernel** installed into the **flash memory** will search the root filesystem using the **UUID**, so you have to change the partition UUID on the new disk once formatted, otherwise the boot process will fail. If you forget this step, like I did, you can attach to the **serial console** and fix the problem.
+<code bash>
+mkfs.ext4 /dev/sdb1
+mkswap /dev/sdb2
+blkid /dev/sdb1
+blkid /dev/sdb2
+# Take note of the UUIDs of new partitions.
+mount /dev/sdb1 /mnt
+cd /mnt
+ssh root@qnap.lan 'dump -0 -a -b 64 -f - /dev/sda1' | restore -r -b 64 -f -
+vi /mnt/etc/fstab
+# Update the UUIDs in fstab.
+</code>
+**WARNING**: It is advisable to change the UUID of the root filesystem to match the one on the old disk, this is beacuse the initramfs stored into the QNAP flash memory will search the rootfs by UUID. It should be possibile change the UUID on the unmounte partition using **tune2fs -U <UUID> /dev/sdb1**. I forgot to make this step, so I had to attach a serial cable to the QNAP and fix the boot process manually. See below.
+Fortunately the hard disk was seen correctly both on the computer and later on the QNAP, I mean in particular the overall size and the logical/physical sector size. This is a subtle matter, e.g. the QNAP bootloader seems limited to disk size of 2 Tb, during bootstrap you can read this on the **serial console**:
 <code>
+Model: WDC WD40PURZ-85AKKY0    Firm: 80.00B80 Ser#:    WD-WX12D81D4P9U
+    Type: Hard Disk
+    Supports 48-bit addressing
+    Capacity: 1718295.8 MB = 1678.0 GB (-775897424 x 512)
 </code>
+but from the kernel point of view, everything seems ok:
+<code>
+scsi 1:0:0:0: Direct-Access     ATA      WDC WD40PURZ-85A 0B80 PQ: 0 ANSI: 5
+sd 1:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
+sd 1:0:0:0: [sda] 4096-byte physical blocks
+sd 1:0:0:0: [sda] Write Protect is off
+sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+ sda: sda1 sda2 sda3
+sd 1:0:0:0: [sda] Attached SCSI disk
+</code>
+==== Beware the UUID of root filesystem ====
+Once the new disk was partitioned, formatted and populated using restore, I installed it into the QNAP. Unfortunately it didn't boot. The **initramfs** installed into the **flash memory** looks for the root filesystem using the **UUID**, so you have to set the partition UUID on the new disk to match the old one, otherwise the boot process will fail.
+If you forget this step (like I did) you can attach to the **serial console** and fix the problem.
+When the boot process fails, you get the //initramfs// prompt, here you can temporarly fix the problem by making a symlink from the new UUID to the missing one:
+<code>
+(initramfs) cd /dev/disk/by-uuid/
+(initramfs) ln -s <new-UUID> <old-UUID>
+(initramfs) exit
+</code>
+The QNAP should boot. To make a permanent fix you have to create a file **/etc/initramfs-tools/conf.d/root** containing the following:
+<code>
+ROOT=/dev/disk/by-uuid/<new-UUID>
+</code>
+Update the initramfs with:
+<code>
+update-initramfs -k all -u
+</code>
+The **update-initramsf** on the QNAP will call the **flash-kernel** tool to write the **kernel** and the **initramfs** images to the proper flash partitions. Flashing the images requires some minutes. You can verify that the proper //rootfs// device is written into the //initramfs// image: unpack its content by executing:
+<code>
+unmkinitramfs /boot/initrd.img-4.19.0-18-marvell ./initramfs/
+</code>
+Verify that inside the file **/conf/param.conf** is declared the proper device:
+<file>
+ROOT="/dev/disk/by-uuid/423996a4-7a6c-497d-bc45-ecfa98385c47"
+</file>
+Now try to reboot. If the problem is fixed, you may remove the file **/etc/initramfs-tools/conf.d/root** and run **update-initramfs** again: now the proper rootfs will be autodetected.
+===== USB audio dongle =====
+I use the QNAP also as a **media player** because it stores all my audio files. I attached it to my HiFi amplifier through an **USB audio dongle** and an **audio cable** (3.5 mm jack - RCA stereo plugs).
+I faced a problem with that audio USB interface, because at every reboot the device is not working and it does not show in **lsusb** output. The manual workaround was to unplup and re-plug the device into the USB port.
+Fortunately it is possibile to force the re-initialization of the USB controller with the following script:
+<code bash>
+#!/bin/sh
+# If the USB audio device is missing, try to reset the USB controller.
+# USB 2.0 devices may be under /sys/bus/pci/drivers/ehci_hcd instead.
+PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+lsusb | grep -q 'JMTek, LLC. audio controller'
+RET=$?
+if [ "$RET" -ne "0" ]; then
+    echo "USB audio device missing, trying to reset the bus."
+    cd /sys/bus/pci/drivers/xhci_hcd
+    echo -n "0000:02:00.0" > unbind
+    sleep 1
+    echo -n "0000:02:00.0" > bind
+fi
+</code>
+So I created a systemd service to be run when the host reaches the multi-user target. Create the file **/etc/systemd/system/usb-audio-dongle-reset.service**:
+<file>
+# /etc/systemd/system/usb-audio-dongle-reset.service
+#
+# Service executed once the system has reached the multi-user status.
+#
+#  Type=oneshot         The unit is up after the main process exits.
+#  RemainAfterExit=yes  The service shall be considered active even
+#                       when all its processes exited.
+#
+# Eanble the service with:
+#   systemctl enable my-startup.service
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStart=/usr/local/sbin/usb-audio-dongle-reset
+[Install]
+WantedBy=multi-user.target
+</file>
+Enable and start the service with:
+<code>
+systemctl --now enable usb-audio-dongle-reset.service
+</code>
+===== Downgrading the kernel =====
+Is QNAP TS-120 is supported by the **flash-kernel** tool (notice the return code is zero):
+<code>
+flash-kernel --supported; echo $?
+</code>
+<code>
+ls -l /boot/vmlinuz-*
+-rw-r--r-- 1 root root 2058840 Sep 29  2021 /boot/vmlinuz-4.19.0-18-marvell
+-rw-r--r-- 1 root root 2056592 Jun 30  2022 /boot/vmlinuz-4.19.0-21-marvell
+-rw-r--r-- 1 root root 2069944 Dec 12  2021 /boot/vmlinuz-4.9.0-17-marvell
+</code>
+<code>
+flash-kernel --force 4.19.0-18-marvell
+</code>
+The flash procedure requires some time to coplete; writing about 2 Mb of **kernel** image and 6 Mb of **initramfs** image required **12 minutes**.
+From the output when flashing a kernel you can also know where the Device Tree Blob (DTB) is taken:
 <code>
-# flash-kernel
 kirkwood-qnap: machine: QNAP TS219 family
 Using DTB: kirkwood-ts219-6282.dtb
-Installing /usr/lib/linux-image-4.19.0-18-marvell/kirkwood-ts219-6282.dtb into /boot/dtbs/4.19.0-18-marvell/./kirkwood-ts219-6282.dtb
+Installing /usr/lib/linux-image-4.19.0-21-marvell/kirkwood-ts219-6282.dtb into /boot/dtbs/4.19.0-21-marvell/./kirkwood-ts219-6282.dtb
 Taking backup of kirkwood-ts219-6282.dtb.
 Installing new kirkwood-ts219-6282.dtb.
-flash-kernel: installing version 4.19.0-18-marvell
+Installing /usr/lib/linux-image-4.19.0-21-marvell/kirkwood-ts219-6282.dtb into /boot/dtbs/4.19.0-21-marvell/./kirkwood-ts219-6282.dtb
-flash-kernel: appending /usr/lib/linux-image-4.19.0-18-marvell/kirkwood-ts219-6282.dtb to kernel
+Taking backup of kirkwood-ts219-6282.dtb.
+Installing new kirkwood-ts219-6282.dtb.
+flash-kernel: installing version 4.19.0-21-marvell
+flash-kernel: appending /usr/lib/linux-image-4.19.0-21-marvell/kirkwood-ts219-6282.dtb to kernel
 Generating kernel u-boot image... done.
-Flashing kernel (using 2070050/2097152 bytes)... done.
+Flashing kernel (using 2067802/2097152 bytes)... done.
-Flashing initramfs (using 6093136/9437184 bytes)... done.
+Flashing initramfs (using 6101378/9437184 bytes)... done.
+</code>
+===== Cooling Fan =====
+The original fan is **50x50x15 mm** and is marked as:
+  * **Y.S. TECH**
+  * **FD125015LB**
+  * **DC12V 0.085A**
+The pinout of the QNAP TS-120 fan is:
+^ PIN  ^ Color  ^ Function  ^
+|  1 | Black   | Ground  |
+|  2 | Yellow  | +12 v DC  |
+|  3 | Green   | Tachometer (sense) signal  |
+|  4 | Blue    | PWM control signal  |
+This is the **standard pinout of a CPU fan** with PWM speed control an tachometer sensor:
+^ PIN  ^ Color   ^ Function          ^
+|    1 | Black   | Ground            |
+|    2 | Red     | +12 v DC          |
+|    3 | Yellow  | Tachometer Sense  |
+|    4 | Blue    | PWM Control       |
+To control the fan speed you can use the **qcontrol** tool:
+<code>
+qcontrol fanspeed {stop|silence|low|medium|high|full}
+</code>
+===== Automatic power-on =====
+To enable automatic power-on when power is restored (if the device was not powered down correctly):
+<code>
+qcontrol --direct autopower on
+</code>
+===== Temperature sensor =====
+<code>
+cat /sys/class/hwmon/hwmon0/temp1_input
 </code>