User Tools

Site Tools


doc:appunti:hardware:qnap_ts-120

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
doc:appunti:hardware:qnap_ts-120 [2022/02/12 08:04] – [Serial Console] niccolodoc:appunti:hardware:qnap_ts-120 [2025/04/01 12:55] (current) – [Cooling Fan] niccolo
Line 107: Line 107:
 ^ 4  | GND       | ^ 4  | GND       |
  
-This is the boot process captured from the serial line:+This is the boot process captured from the serial line. At the end of the bootstrap you will get a **login prompt**.
  
 <code> <code>
Line 138: Line 138:
 </code> </code>
  
-The problem is that the rtc support is **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**.+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]]**. 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]]**.
Line 157: Line 157:
   #/sbin/hwclock --rtc=$dev --systz   #/sbin/hwclock --rtc=$dev --systz
 </code> </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
 +24hr            : 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 ===== ===== Upgrading to 4 Tb Hard Disk =====
Line 252: 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. 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 $?
 +0
 +</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>
  
doc/appunti/hardware/qnap_ts-120.1644649462.txt.gz · Last modified: by niccolo