@bodhi
I think I need to change the poweroff node in the DTS

Current

compatible = "synology,power-off";

To

compatible = "qnap,power-off";

Are there any other changes I should make ?

Richard,

> I think I need to change the poweroff node in the
> DTS

No need to. That's the right keyword

Quote

compatible = "synology,power-off";

If it does not work, then we need to patch the code to send the correct command.

In the event we need to do that, you need to make sure whether 31 is the hex value or decimal. So the command could be 31 or 49.

The DS116 should work with this poweroff driver (I think the author must have tested that, because DS116 is mainlined)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi
I looked up the kernel commit for the driver HERE

which included

Quote

+Required Properties:
+- compatible: Should be "qnap,power-off"
+
+- reg: Address and length of the register set for UART1
+- clocks: tclk clock

But I will try it as is first.

EDIT
Sorry if comment came across a bit terse, I was interrupted, what I meant was I will try as is first because I agree with your comment re DS116 being mainline.



Edited 1 time(s). Last edit at 05/15/2019 12:10AM by richjn.

Richard,

> Sorry if comment came across a bit terse, I was
> interrupted, what I meant was I will try as is
> first because I agree with your comment re DS116
> being mainline.

It's OK!

That code is a bit old. Here is the latest:

static const struct power_off_cfg synology_power_off_cfg = {
        .baud = 9600,
        .cmd = '1',
};

static const struct of_device_id qnap_power_off_of_match_table[] = {
        { .compatible = "qnap,power-off",
          .data = &qnap_power_off_cfg,
        },
        { .compatible = "synology,power-off",
          .data = &synology_power_off_cfg,
        },
        {}
};

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/15/2019 12:22AM by bodhi.

@bodhi
Cool

Whats not so cool though is I forgot -j2 when I started compiling the kernel :( too late to be worth starting over but watching paint dry will be a little longer than I hoped, we're up to dvb drivers at the moment.



Edited 1 time(s). Last edit at 05/15/2019 12:26AM by richjn.

@bodhi
Whilst waiting for the kernel to finish I was just thinking about the fan control and although it is trivial to write a userspace script to echo "0" or "1" to /sys/class/hwmon/hwmon1/fan1_target on cpu temp changes it would be much nicer to just "package" control into the DTS. Is there a built in cpu temp trigger we could use in a similar fashion to how you added the led trigger ?

Richard,

> Whilst waiting for the kernel to finish I was just
> thinking about the fan control and although it is
> trivial to write a userspace script to echo "0" or
> "1" to /sys/class/hwmon/hwmon1/fan1_target on cpu
> temp changes it would be much nicer to just
> "package" control into the DTS. Is there a built
> in cpu temp trigger we could use in a similar
> fashion to how you added the led trigger ?


This is actually in the domain of hwmon thermal trigger. And thermal drivers are availble for both Marvell Kirkwood and Armada, already in mainline. But their implementation are not enough for us at the moment. So you see even they available, I only activate them as loadable modules in the released kernels.

ATM, I think a script is the best road to take.

But for experiment, they can be loaded, and their triggers will show up.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/15/2019 03:06AM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> Richard,
>
> > Whilst waiting for the kernel to finish I was
> just
> > thinking about the fan control and although it
> is
> > trivial to write a userspace script to echo "0"
> or
> > "1" to /sys/class/hwmon/hwmon1/fan1_target on
> cpu
> > temp changes it would be much nicer to just
> > "package" control into the DTS. Is there a
> built
> > in cpu temp trigger we could use in a similar
> > fashion to how you added the led trigger ?
>
>
> This is actually in the domain of hwmon thermal
> trigger. And thermal drivers are availble for both
> Marvell Kirkwood and Armada, already in mainline.
> But their implementation are not enough for us at
> the moment. So you see even they available, I only
> activate them as loadable modules in the released
> kernels.
>
> ATM, I think a script is the best road to take.
>
> But for experiment, they can be loaded, and their
> triggers will show up.

I forgot :) I've turned this on as in-kernel module a while ago. But it still needs a DTS node to activate.

CONFIG_ARMADA_THERMAL=y
CONFIG_THERMAL_HWMON=y

But

# CONFIG_CPU_THERMAL is not set

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 05/15/2019 03:38AM by bodhi.

@bodhi
I may need to recompile the kernel again.... not sure. In a moment of not thinking I did a make clean in the build directory after the kernel compile and hence blew away the new zImage before I had copied it to boot.. Doh! I did create a new uInitrd after installing the new built packages.

The poweroff command still leaves things powered up but I'm unclear if this is because of my zImage oversight or because I need to change the address sent to ttyS1. Would the zImage matter in this circumstance as the kernel version is unchanged ?

If I do need to rebuild I will enable CONFIG_CPU_THERMAL whilst I'm at it plus use linux-5.1.2 which is out now.

Message to self: Drinking a couple of beers whilst waiting for kernel to build = bad day!

Richard,

> The poweroff command still leaves things powered
> up but I'm unclear if this is because of my zImage
> oversight or because I need to change the address
> sent to ttyS1. Would the zImage matter in this
> circumstance as the kernel version is unchanged ?

No, zImage has already been loaded and kernel is running in memory.

>
> If I do need to rebuild I will enable
> CONFIG_CPU_THERMAL whilst I'm at it plus use
> linux-5.1.2 which is out now.

After that, boot the kernel and check your trigger options

cat /sys/leds/*/trigger

>
> Message to self: Drinking a couple of beers whilst
> waiting for kernel to build = bad day!

But a few more beers will be even more interesting and perhaps could have reversed that misstep (been there done that with too many glasses of shiraz) :))

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Richard,

Most likely the Synology poweroff code need to be modified, I suspect so.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi
I think you may be right the answer is more beer not less, oh and don't mention the shiraz it is my preferred red and now you have mentioned it I may need to fetch a bottle :)

Started building linux-5.1.2 with the extra config enabled and this time I remembered -j2

@bodhi

Quote

Most likely the Synology poweroff code need to be modified, I suspect so.

Should I abort the build and address the poweroff code first then ?

The address for pulling the plug is 0x31 but just to be clear this literally pulls the plug and doesn't commence a shutdown or anything like that.

In our v9 DTS we have addressed the location as

reg = <0x12100 0x100

Can I get away with just changing the DTS or do I need to modify the kernel source or both ?

Richard,

> The address for pulling the plug is 0x31 but just
> to be clear this literally pulls the plug and
> doesn't commence a shutdown or anything like
> that.

Yes. With that microcontroller doing its thing, if you want to send 0x31, it should be the last thing happens in initscript (i.e. after synching disk and turn off LED).

The shutdown action to echo that 0x31 code to ttys01 should be in /etc/init.d/halt (at the end).

>
> In our v9 DTS we have addressed the location as
>

> reg = <0x12100 0x100
>

> Can I get away with just changing the DTS or do I
> need to modify the kernel source or both ?

That I have to read the driver code again to be sure.

Will be back in another 12hrs or so.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

Quote

Will be back in another 12hrs or so

I'm happy to do the leg work I'm just conscious you are far more knowledgeable than I am so asking you before I burn hours seems a sensible thing to do.

I'm quite a way through the new kernel build and anyway I would like to see if the new triggers turn up so plan of action.

1) Finnish build and see what new triggers turn up
2) Try as is DTS for poweroff and if fails change address in DTS and if that fails
3) Change address in source code.

EDIT
And just thinking about it, if we needed a patch / kernel for each model Synology that would suck! so hopefully DTS is enough.



Edited 1 time(s). Last edit at 05/15/2019 05:32AM by richjn.

@bodhi
I've taken a quick look and it just seems to be sending a 1 byte char for "compatable synology, poweroff" so if I have my head around this echo 1 > /dev/ttyS1 would be the same as printf "\\31" > /dev/ttyS1.

Easy enough to test once the kernel has finished building, if it works I think we just need to amend the DTS

@bodhi
Kernel rebuilt and the extra bottle of shiraz enabled me to complete without further mistakes :)

No need to change DTS so we are still on v9 and last line of poweroff from console;

[  490.764237] qnap_power_off: triggering power-off...

and everything is switched off!

Checked for triggers before and after kernel update with new CONFIG_CPU_THERMAL=y and a diff showed no changes;

cat /sys/class/leds/*/trigger

none rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport usb-gadget usb-host timer oneshot disk-activity disk-read disk-write [ide-disk1] ide-disk2 mtd nand-disk heartbeat gpio default-on flash torch panic f1072004.mdio-mii:01:link f1072004.mdio-mii:01:1Gbps f1072004.mdio-mii:01:100Mbps f1072004.mdio-mii:01:10Mbps

Richard,

>

> [  490.764237] qnap_power_off: triggering
> power-off...
>

> and everything is switched off!

Cool!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi
With no new triggers showing up (from the config addition) are we going to leave switching fans from low to high to users to implement via a script ? Once I have done mine I could share it here for others to use / base theirs on.

If we are leaving it to end users I think we should clean up the fan section of v9 DTS which still contains 7 speeds in the form of an rpm map. As we now know there is no fine grained rpm control on this box and so I was wondering is a "map" still the correct way to declare it ? if so I will just reduce the map to two entries.

Once the DTS fan control is finalized and the project largely complete (or is there something else you would wanted to tick off) I would like to flash my system mtds fw_envs etc. I did post the output you requested earlier but wasn't a 100% sure if you had wanted me to post it in this thread or start a new one ?

EDIT
Just adding what we have in hwmon

root@debian:~# cat /sys/class/hwmon/hwmon0/name
f1072004mdiomii01
root@debian:~# cat /sys/class/hwmon/hwmon1/name
gpio_fan
root@debian:~# cat /sys/class/hwmon/hwmon2/name
f10e4078.thermal
root@debian:~#

Edited 1 time(s). Last edit at 05/15/2019 06:54PM by richjn.

Away for 24 hours

Richard,

> are we going to leave switching fans
> from low to high to users to implement via a
> script ? Once I have done mine I could share it
> here for others to use / base theirs on.

Yes. That would be great!


> If we are leaving it to end users I think we
> should clean up the fan section of v9 DTS which
> still contains 7 speeds in the form of an rpm map.
> As we now know there is no fine grained rpm
> control on this box and so I was wondering is a
> "map" still the correct way to declare it ? if so
> I will just reduce the map to two entries.

I think we shoudl try the DS116 definition one more time to make sure.

gpio-fan {
			compatible = "gpio-fan";
			gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>,
				<&gpio1 17 GPIO_ACTIVE_HIGH>,
				<&gpio1 16 GPIO_ACTIVE_HIGH>;
			gpio-fan,speed-map = <   0 0
					      1500 1
					      2500 2
					      3000 3
					      3400 4
					      3700 5
					      3900 6
					      4000 7>;
			#cooling-cells = <2>;
		};

> Once the DTS fan control is finalized and the
> project largely complete (or is there something
> else you would wanted to tick off) I would like to
> flash my system mtds fw_envs etc. I did post the
> output you requested earlier but wasn't a 100%
> sure if you had wanted me to post it in this
> thread or start a new one ?

Please put every thing below in 1 new post in this thread:

Quote

- Boot with the serial console.
- Login and

cat /proc/mtd
cat /etc/fw_env.config
fw_printenv

And post the entire serial console log.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/16/2019 04:28AM by bodhi.

I recently had some success measuring fan speeds on a similar device by marking one of the fan blades with a crayon and using "slo-mo" mode on my iphone to record a few seconds of the fan spinning at various speed settings. It's fairly easy to take that video and count the frames it takes the marked blade to complete a revolution and use that to calculate the RPMs.

I'm sure there are better ways to make that measurement but It seemed the easiest/most accurate way using just things I had available at the time.

@bodhi

Quote
I think we shoudl try the DS116 definition one more time to make sure.

Good call! Not sure if something has changed (extra kernel config) or I just missed it before but with the DS116 config we now have more control. I have redone the map to reflect the actual speed change points noted by echoing in 50 increments to fan1_target and utilizing my wife's hearing, she can hear a pin drop at 200 meters! very inconvenient if I want to sneak in late, but @100001101000 suggestion is both creative and probably a more accurate way of doing it.

I note that echoing the map numbers 1, 2, 3, 4, doesn't do anything you have to echo the rpm but maybe I have just misunderstood how the map works.

Also to note "0" is now 0 rpm echo anything greater than 0 i.e. "1" takes you straight to 1,500 other speed changes kick in at the new values in the map.

The new map as per v11 DTS attached (I had posted a v10 previously)

gpio-fan {
			compatible = "gpio-fan";
			gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>,
				<&gpio1 17 GPIO_ACTIVE_HIGH>,
				<&gpio1 16 GPIO_ACTIVE_HIGH>;
			gpio-fan,speed-map = <   0 0
					      1500 1
					      2500 2
					      2600 3
					      3100 4>;
			#cooling-cells = <2>;
		};

Any further action needed on this or are we done with the fan now ?

@bodhi
Other than any last thoughts you may have on the fan the only thing I can think of that is currently not addressed is the NIC led's.

To recap, the nic's and hdd's leds are powered up via gpio 6 as a group and our current ide-disk1 trigger flashes all of them on hdd activity which is not the desired action for the nic leds which we want to flash on network activity.

In stock I think I am correct in stating that all leds are handled by the daemon scemd which itself uses a propriety kernel module synobios. An effort to re-create this module has been carried out HERE

Personally I'm happy to look for hints in propriety software but have no desire to attempt to re-engineer.

Do you have any thoughts on if we should try to resolve this one now or leave it to another day / others ?

Richard,

The fan is good to go!
.
The NIC LED is not important. HHD LED is more important to be correct. So I think we are done for now. I declare victory :) well done everybody.

And also, thanks 100000 for good suggestions along the way!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi
Echo your sentiments, thanks to everyone for contributing in being able to add the RS816 to the supported list!

I use python’s pySerial module to send commands to an on-board microcontroller similar to the one on your device. I’ve found that it’s a bit more reliable than echoing bytes to the device, it also makes it pretty easy to handle the response bytes that come back.

I’ve got that code published here if you’re interested:
https://github.com/1000001101000/Python_buffalo_libmicon

The terastation’s commands are variable-length and include a checksum and different read/write command modes,
If I read correctly It looks like the synology commands are fairly simple single byte commands which should be comparatively easy to implement.

I’m currently only using it to stop the power led blinking at startup and to change the lcd message to something other than “booting disk0...”. Someday ai hope to spend sometime writing something that monitors disk health/etc that uses it.

@bodhi

Quote

Please put every thing below in 1 new post in this thread

cat /proc/mtd

dev:    size   erasesize  name
mtd0: 00400000 00001000 "boot"
mtd1: 00400000 00001000 "spi-rootfs"

cat /etc/fw_env.config

# MTD device name       Device offset   Env. size       Flash sector size       Number of sectors

/dev/mtd1               0x0000          0x80000         0x20000                 4

fw_printenv

Warning: Bad CRC, using default environment
bootcmd=run distro_bootcmd
bootdelay=2
baudrate=115200
stdin=serial,cros-ec-keyb,usbkbd
stdout=serial,vidconsole
stderr=serial,vidconsole
ethaddr=00:00:11:22:33:44
eth1addr=00:00:11:22:33:45
eth3addr=00:00:11:22:33:46
eth5addr=00:00:11:22:33:47
ipaddr=1.2.3.4
host_boot=if host dev ${devnum}; then setenv devtype host; run scan_dev_for_boot_part; fi
sata_boot=if sata dev ${devnum}; then setenv devtype sata; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then setenv scsi_need_init false; scsi scan; fi
scsi_boot=run scsi_init; if scsi dev ${devnum}; then setenv devtype scsi; run scan_dev_for_boot_part; fi
virtio_boot=if virtio dev ${devnum}; then setenv devtype virtio; run scan_dev_for_boot_part; fi
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_script_dhcp=boot.scr.uimg
boot_targets=host1 host0
boot_syslinux_conf=extlinux/extlinux.conf
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
bootcmd_host1=setenv devnum 1; run host_boot
bootcmd_host0=setenv devnum 0; run host_boot
distro_bootcmd=setenv scsi_need_init; for target in ${boot_targets}; do run bootcmd_${target}; done
bootm_size=0x10000000
kernel_addr_r=0x1000000
fdt_addr_r=0xc00000
ramdisk_addr_r=0x2000000
scriptaddr=0x1000
pxefile_addr_r=0x2000

@100001101000
Interesting I will take a look!

I'm currently stopping the power led blinking in rc.local

echo 4 > /dev/ttyS1

And turning the status light On > Green

echo 8 > /dev/ttyS1

Later I will add a script to change those to Orange > blinking based on smartd & mdmon errors

@bodhi
Missed one of the fan speeds of the v11 DTS
v12 and final attached.