fan continously runs on kernel 5.8 but I need to use 5. kernel for PCIe sata card
#1
Hi all

so I have an issue and i need to know the options available to me, so I have a Rockpro64  NAS case setup ,running Openmediavault  on armbian buster wit kernel 4.4 and ats to control the fan .

My issue is that I get the same fault described in several of the thread regarding the PCIe card , my card fails under intense uploading mounts as read only then eventually remounts as a different drive. not ideal for a Nas.  Sad

so I decided to get the marvel  88SE9230 PCIe sata card and I can confirm that binding the driver to the card using a udev rule does allows the card to be recognised,

as discussed in this thread here.


Quote:
Code:
root@rockpro64:~# nano /etc/udev/rules.d/99-marvell.rules

RUN+="/bin/bash -c 'echo 0000:01:00.0 > /sys/bus/pci/drivers/ahci/bind'"


however the drives are not discovered , so as others have said in other threads I changed to the latest available stable kernel 5.8.13 , success! the drives are discovered and I can successfully mount them.

However the problem I discovered is that all the kernels I tried on 5.(+) caused the fan to run continuously , I couldn't get ats to control it! and fresh image with 5.8 kernel  on armbian bullseye , buster (upgraded to 5.8) or bionic with 5.8 would all have the fan running continuously.

so here in lies the problem what are my options?

A)   do I have to either have the pcie card that doesn't result in a fault (marvell 88SE9230) and have the fan running constantly? , or have it disconnected ?
B) use the asmedia PCIe card with existing 4.4 kernel so at least I can control the fan but I cant use the card intensively.
C) reduce the sata link speed on the asmedia PCIe as patsnew mentioned in another thread and not use the card intensively.


Quote:You can also try reducing the SATA link speed using "libata.force=1.5G" or "libata.force=3G" in the kernel arguments. That seems to have fixed some intermittent problems with my ASMedia SATA card.



or do I have other options ? any advice you guys can give would be great.
  Reply
#2
The 5.x kernels define a pwm-fan device in the device tree, but don't set up any parameters to control it, so the kernel turns it fully on by default.

On 5.x kernels, you should have a sysfs file /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1 which can be used to control the fan from userspace, e.g.
Code:
echo 128 > /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1
writing values 0 to 255 to the file will set the speed to approx 0 to 100%.

More advanced, you can have the kernel thermal subsystem to control the fan, e.g. by applying this device tree overlay to your device tree - it runs the fan progressively more as CPU speed rises through 54-64°C. For more detail Read the documentation on how thermal devices are described in device trees.
  Reply
#3
Thank you so much for the detailed explanation and solutions.

I sort of understand how the device tree works and what overlays are but could you point me to a tutorial that explains how to apply an overlay to the device tree .

Out of interest do you believe that the more advanced solution is better ,as I have seen that some people suggest running the fan continuously although at a lower duty cycle as this is better for a NAS case setup.
  Reply
#4
You can apply the overlay a few different ways - you can use the fdtoverlay tool from the device-tree-compiler package to take the base .dtb and the compiled overlay and write the result to a compiled flat device tree:

Code:
fdtoverlay -i base.dtb -o base_with_overlay.dtb overlay.dtbo


... then use the base_with_overlay.dtb to boot.

Or you can get U-boot to load and apply it in-memory during boot - it sounds like Armbian supports this for Allwinner but maybe not for Rockchip? I have not been using Armbian so I don't know the details of how this works. I use a custom U-Boot script to apply the overlays using the fdt apply command.

Whether or not this is better than running the fan constantly depends on what you want - I have an open case with the fan mounted on the CPU heatsink, so it makes sense to control it according to the CPU temperature reading. It is normally off unless I'm compiling something using all 6 cores. For your use-case, it sounds like you have the NAS case and so maybe have the fan mounted on the case, not the CPU heatsink, and the fan is cooling not only the board but some HDDs, so maybe it is better to run the fan all the time to cool the whole case - depends what you think really.
  Reply
#5
(10-20-2020, 10:38 AM)sigmaris Wrote: You can apply the overlay a few different ways - you can use the fdtoverlay tool from the device-tree-compiler package to take the base .dtb and the compiled overlay and write the result to a compiled flat device tree:

Code:
fdtoverlay -i base.dtb -o base_with_overlay.dtb overlay.dtbo


... then use the base_with_overlay.dtb to boot.

Or you can get U-boot to load and apply it in-memory during boot - it sounds like Armbian supports this for Allwinner but maybe not for Rockchip? I have not been using Armbian so I don't know the details of how this works. I use a custom U-Boot script to apply the overlays using the fdt apply command.

Whether or not this is better than running the fan constantly depends on what you want - I have an open case with the fan mounted on the CPU heatsink, so it makes sense to control it according to the CPU temperature reading. It is normally off unless I'm compiling something using all 6 cores. For your use-case, it sounds like you have the NAS case and so maybe have the fan mounted on the case, not the CPU heatsink, and the fan is cooling not only the board but some HDDs, so maybe it is better to run the fan all the time to cool the whole case - depends what you think really.


Hearing you explain it I think your right, with a sealed case, the tall heatsink, the 80mm case fan and trying to cool the SSD's as well I should probably have it running all the time just at a lower speed rather than flat out. I think ill just add
Code:
echo 128 > /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1


 to the /etc/rc.local file and have it control the fan speed manually at boot.

I'll run some some tests to see what is the best value to use the fan at for my setup .

I appreciate you taking the time to explain how to apply overlays to the device tree I will definitely be doing more research into this, now that I understand it a little better,
its a very interesting topic that I've seen mentioned a few times but never really understood it or gave it much thought .

thanks again for your help and advice . Smile
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Mainline U-Boot with SPI, NVMe and SATA boot support sigmaris 64 17,283 11-30-2020, 02:41 PM
Last Post: Waryle
  Rockpro64 with PCI FC Card - Not booting (Sometimes) MSteam 1 228 10-25-2020, 07:42 PM
Last Post: MSteam
  RockPro64 SSD Expansion Board/SATA Shield as0zial 5 993 10-18-2020, 08:05 PM
Last Post: revoman
  4pin Connector for dual SATA m.ekstrom 4 1,124 07-28-2020, 07:07 AM
Last Post: mabs
  PCIe x4 mode - Lane 3 failure acdkyn 1 747 04-24-2020, 01:32 PM
Last Post: kuleszdl
  micro SD Card Slot Spring not working, Cant boot mjembd 1 537 04-16-2020, 12:30 AM
Last Post: mjembd
  Defective? PCI-E -> SATA card no work good unregisteredidiot 11 3,474 02-19-2020, 09:08 AM
Last Post: fysa
  for what purpose Pine64 added PCIEx4 card on this sbc ? seaurchin 4 1,042 11-25-2019, 11:33 AM
Last Post: dukla2000
  Considering buying and question on the PCIe slot MobileJAD 25 16,460 11-07-2019, 03:10 PM
Last Post: hmuller
  RockPro64 pcie Gpu Davidos 1 981 06-09-2019, 02:09 PM
Last Post: guannais

Forum Jump:


Users browsing this thread: 1 Guest(s)