doc:appunti:hardware:qnap_ts-120
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
doc:appunti:hardware:qnap_ts-120 [2022/02/12 08:04] – [Serial Console] niccolo | doc: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**. |
< | < | ||
Line 138: | Line 138: | ||
</ | </ | ||
- | 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 **/ | + | The problem is that kernel packages **%%linux-image-4.19.0-*-marvell%%** include |
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:// | 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:// | ||
Line 157: | Line 157: | ||
#/ | #/ | ||
</ | </ | ||
+ | |||
+ | ===== Problem with the I2C bus locked ===== | ||
+ | |||
+ | Booting the **4.9.0-17** kernel, the '' | ||
+ | |||
+ | < | ||
+ | i2c /dev entries driver | ||
+ | i2c i2c-0: mv64xxx_i2c_fsm: | ||
+ | rtc-s35390a 0-0030: error resetting chip | ||
+ | rtc-s35390a: | ||
+ | </ | ||
+ | |||
+ | Booting the **4.19.0-21** kernel, the error message is slightly different: | ||
+ | |||
+ | < | ||
+ | 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: | ||
+ | </ | ||
+ | |||
+ | This means that the I2C bus is locked and the RTC kernel module cannot load properly: | ||
+ | |||
+ | < | ||
+ | modprobe rtc-s35390a | ||
+ | </ | ||
+ | |||
+ | again we can read the '' | ||
+ | |||
+ | < | ||
+ | i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0 | ||
+ | rtc-s35390a 0-0030: error resetting chip | ||
+ | rtc-s35390a: | ||
+ | </ | ||
+ | |||
+ | 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 **/ | ||
+ | |||
+ | < | ||
+ | cat / | ||
+ | rtc_time | ||
+ | rtc_date | ||
+ | alrm_time | ||
+ | alrm_date | ||
+ | alarm_IRQ | ||
+ | alrm_pending | ||
+ | update IRQ enabled | ||
+ | periodic IRQ enabled | ||
+ | periodic IRQ frequency | ||
+ | max user IRQ frequency | ||
+ | 24hr : yes | ||
+ | </ | ||
+ | |||
+ | **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:// | ||
+ | |||
===== 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 **/ | Now try to reboot. If the problem is fixed, you may remove the file **/ | ||
+ | |||
+ | ===== 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 / | ||
+ | PATH="/ | ||
+ | lsusb | grep -q ' | ||
+ | RET=$? | ||
+ | if [ " | ||
+ | echo "USB audio device missing, trying to reset the bus." | ||
+ | cd / | ||
+ | echo -n " | ||
+ | sleep 1 | ||
+ | echo -n " | ||
+ | fi | ||
+ | </ | ||
+ | |||
+ | So I created a systemd service to be run when the host reaches the multi-user target. Create the file **/ | ||
+ | |||
+ | < | ||
+ | # / | ||
+ | # | ||
+ | # Service executed once the system has reached the multi-user status. | ||
+ | # | ||
+ | # Type=oneshot | ||
+ | # RemainAfterExit=yes | ||
+ | # when all its processes exited. | ||
+ | # | ||
+ | # Eanble the service with: | ||
+ | # | ||
+ | |||
+ | [Service] | ||
+ | Type=oneshot | ||
+ | RemainAfterExit=yes | ||
+ | ExecStart=/ | ||
+ | |||
+ | [Install] | ||
+ | WantedBy=multi-user.target | ||
+ | </ | ||
+ | |||
+ | Enable and start the service with: | ||
+ | |||
+ | < | ||
+ | systemctl --now enable usb-audio-dongle-reset.service | ||
+ | </ | ||
+ | |||
+ | ===== Downgrading the kernel ===== | ||
+ | |||
+ | Is QNAP TS-120 is supported by the **flash-kernel** tool (notice the return code is zero): | ||
+ | |||
+ | < | ||
+ | flash-kernel --supported; | ||
+ | 0 | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | ls -l / | ||
+ | -rw-r--r-- 1 root root 2058840 Sep 29 2021 / | ||
+ | -rw-r--r-- 1 root root 2056592 Jun 30 2022 / | ||
+ | -rw-r--r-- 1 root root 2069944 Dec 12 2021 / | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | flash-kernel --force 4.19.0-18-marvell | ||
+ | </ | ||
+ | |||
+ | 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: | ||
+ | |||
+ | < | ||
+ | kirkwood-qnap: | ||
+ | Using DTB: kirkwood-ts219-6282.dtb | ||
+ | Installing / | ||
+ | Taking backup of kirkwood-ts219-6282.dtb. | ||
+ | Installing new kirkwood-ts219-6282.dtb. | ||
+ | Installing / | ||
+ | Taking backup of kirkwood-ts219-6282.dtb. | ||
+ | Installing new kirkwood-ts219-6282.dtb. | ||
+ | flash-kernel: | ||
+ | flash-kernel: | ||
+ | Generating kernel u-boot image... done. | ||
+ | Flashing kernel (using 2067802/ | ||
+ | Flashing initramfs (using 6101378/ | ||
+ | </ | ||
+ | |||
+ | ===== 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 | ||
+ | | 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 | ||
+ | | 4 | Blue | PWM Control | ||
+ | |||
+ | |||
+ | To control the fan speed you can use the **qcontrol** tool: | ||
+ | |||
+ | < | ||
+ | qcontrol fanspeed {stop|silence|low|medium|high|full} | ||
+ | </ | ||
+ | |||
+ | ===== Automatic power-on ===== | ||
+ | |||
+ | To enable automatic power-on when power is restored (if the device was not powered down correctly): | ||
+ | |||
+ | < | ||
+ | qcontrol --direct autopower on | ||
+ | </ | ||
+ | |||
+ | ===== Temperature sensor ===== | ||
+ | |||
+ | < | ||
+ | cat / | ||
+ | </ | ||
doc/appunti/hardware/qnap_ts-120.1644649462.txt.gz · Last modified: by niccolo