Differences

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

--- doc:appunti:hardware:qnap_ts-120 [2022/02/11 10:35] – [Console seriale] 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]].
-I connected 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**.
+^ 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**.
-===== Tips =====
+<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>
-hctosys: unable to open rtc device (rtc0)
+[    1.262622] hctosys: unable to open rtc device (rtc0)
-rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0
+[    1.628724] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0
 </code>
-FIXME Why hctosys is started before the rtc0 device becomes available? Is it a problem? Can it be fixed?
+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.
 ===== Upgrading to 4 Tb Hard Disk =====
@@ Line 207: / Line 308: @@
 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>