Differences

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

--- doc:appunti:hardware:qnap_ts-120 [2022/02/11 09:07] – [Dump and restore] 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 reinstall, I **connected the new disk to a GNU/Linux computer**, then partitioned the disk and performed a dump/restore via SSH.
-For partitioning I used **parted**. Fortunately the hard disk was seen correctly both on the computer and later on the QNAP, I mean in particular to 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:
+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:
+<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>
@@ Line 127: / Line 255: @@
     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 ====
-Beware that the **initramfs** installed into the **flash memory** will search 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.
+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.
@@ Line 155: / Line 295: @@
 </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.
+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:
-You can verify that the proper //rootfs// device is written into the //initramfs// image: unpack the the content of your initramfs by executing:
 <code>
@@ Line 169: / Line 307: @@
 </file>
-Now try to reboot. If the problem is fixed, you may remove the file **/etc/initramfs-tools/conf.d/root** and **update-initramfs** again: now the proper rootfs will be autodetected.
+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>
+kirkwood-qnap: machine: QNAP TS219 family
+Using DTB: 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.
+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-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 2067802/2097152 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>