@esion,


Here is the new DTB. Please try.

cd /boot

Download this new DTB.

And then

cd /boot/dts
mv armada-388-wd-ex4100.dtb armada-388-wd-ex4100.dtb.orig
mv ../armada-388-wd-ex4100.dtb .

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



Edited 1 time(s). Last edit at 11/30/2017 05:29PM by bodhi.

Okay, just updating the dts.. Wasn't sure any more.. ;)

Just rebooted with the new dts, serial is showing up:

root@debian:~# dmesg | grep tty
[    0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial mtdparts=armada-nand:5m@0(u-boot),5m@5m(kernel),5m@10m(uRamdisk),441m@15m(image.cfs),15m@456m(rescue_fw),20m@471m(config),10m@491m(reserve1),10m@501m(reserve2)
[    1.152223] console [ttyS0] disabled
[    1.176119] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 22, base_baud = 12500000) is a 16550A
[    1.185213] console [ttyS0] enabled

Changed the port in /etc/mcm-daemon.ini to /dev/ttyS0 and started mcm-daemon with debug enabled:

root@debian:~# mcm-daemon -fd
mcm-daemon[3413]: Bind name to ls. 
mcm-daemon[3413]: Listen on ls for connections. 
mcm-daemon[3413]: Server startup success on port 57367
mcm-daemon[3413]: Got no stop magic, but read 1 bytes!
mcm-daemon[3413]: Buf 0: 0
mcm-daemon[3413]: Try number: 1
mcm-daemon[3413]: Got no stop magic, but read 1 bytes!
mcm-daemon[3413]: Buf 0: 152
mcm-daemon[3413]: Try number: 2
mcm-daemon[3413]: Got no stop magic, but read 1 bytes!
mcm-daemon[3413]: Buf 0: 152
mcm-daemon[3413]: Try number: 3
mcm-daemon[3413]: Got no stop magic, but read 1 bytes!
mcm-daemon[3413]: Buf 0: 152
mcm-daemon[3413]: Try number: 4
mcm-daemon[3413]: Error sending DeviceReady command, exit!

EDIT:
Checking which version of mcm-daemn is currently installed. I think it should be hmartin's.
EDIT2:
Yes, it's hmartin's version.



Edited 2 time(s). Last edit at 11/30/2017 05:57PM by esion.

Unless I am mistaken, this is still not correct.

You have one serial port at 0xf1012000 enabled. This is the uart output from the SoC (since it has the console enabled). Serial at 0xf1012100 is still not being created, and there should be no console present on the Welltrend uart interface.

Your output:

[    1.152223] console [ttyS0] disabled
[    1.176119] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 22, base_baud = 12500000) is a 16550A
[    1.185213] console [ttyS0] enabled

Expected output:

[    1.325450] console [ttyS0] disabled
[    1.349214] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 12500000) is a 16550A
[    1.358241] console [ttyS0] enabled
[    1.394748] f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 24, base_baud = 12500000) is a 16550A

It doesn't seem like the dts has included the second serial port (EX2100 dts):

+                       serial@12100 {
+                               status = "okay";
+                       };

@bodhi?

Can you boot the WD firmware and run dmesg | grep ttyS so we can confirm the second serial is supposed to be at 12100 for the EX4100?



Edited 1 time(s). Last edit at 12/01/2017 12:01AM by hmartin.

@hmartin,

Quote

@bodhi?

Can you boot the WD firmware and run dmesg | grep ttyS so we can confirm the second serial is supposed to be at 12100 for the EX4100?

No, I cannot :) I don't have this box, you forgot that I do not have the hardware :) I only worked on it virtually based on saschadd information. Either saschadd or esion has to do it.

I've attached again both the DTS and DTB files for you to look at.

Also here is the excerpt for both serial ports:

Quote

internal-regs {
i2c@11000 {
status = "okay";
clock-frequency = <100000>;
};

i2c@11100 {
status = "okay";
clock-frequency = <100000>;
};

serial@12000 {
status = "okay";
};

serial@12100 {
status = "okay";
};

ethernet@30000 {
status = "okay";
phy = <&phy1>;
phy-mode = "rgmii-id";
buffer-manager = <&bm>;
bm,pool-long = <2>;
bm,pool-short = <3>;
};

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

Quote
bodhi
No, I cannot :) I don't have this box, you forgot that I do not have the hardware :) I only worked on it virtually based on saschadd information. Either saschadd or esion has to do it.

Sorry about the miscommunication. I know you don't have the EX4100.

I meant about the DTS. Thanks for posting, maybe esion can try again. If the dts is correct, there should be two serial ports in dmesg, not just the one they are seeing.

Booted the original firmware:

Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 44) is a 16550A
console [ttyS0] enabled
f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 45) is a 16550A

Okay, good, that was expected.

Can you please try to boot Debian with the most recent dtb bodhi has posted?

There is no point to trying mcm-daemon if you do not have two serial ports in dmesg after booting. The output of dmesg should be nearly identical to the WD stock firmware output you provided above. If there isn't a ttyS1 created then there's some other issue and I would defer to bodhi as author of the dts ;-)

root@debian:~# dmesg | grep tty
[    0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial mtdparts=armada-nand:5m@0(u-boot),5m@5m(kernel),5m@10m(uRamdisk),441m@15m(image.cfs),15m@456m(rescue_fw),20m@471m(config),10m@491m(reserve1),10m@501m(reserve2)
[    1.152483] console [ttyS0] disabled
[    1.176464] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 22, base_baud = 12500000) is a 16550A
[    1.185520] console [ttyS0] enabled

Not sure if bodhi changed anything in the dts. Could that have anything to do with the kernel command line options?

Can you please print the output of fw_printenv | grep dtb?

@bodhi: I thought you updated the boot process so the DTB was appended to the kernel? In that case, esion needs to replace the appended DTB with the updated version.

https://forum.doozan.com/read.php?2,34103,35370#msg-35370

https://forum.doozan.com/read.php?2,34103,38164#msg-38164



Edited 1 time(s). Last edit at 12/01/2017 01:57PM by hmartin.

root@debian:~# fw_printenv | grep dtb
fdtfile=armada-38x-modular.dtb

Loads the wrong one, right?

fdtfile=armada-38x-modular.dtb

This is leftover from the stock uboot environment. It's not used to boot Debian. So your DTB is appended to the end of the kernel, which is why the second serial port is not being created (because the DTB you downloaded is not being used).

You need to append the updated DTB to the bare kernel, as described in the second link.

Updated the kernel to the latest version with the latest dtb (toootal horror with just a little knowledge and no howto), it seem's to work:

[    0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial mtdparts=armada-nand:5m@0(u-boot),5m@5m(kernel),5m@10m(uRamdisk),441m@15m(image.cfs),15m@456m(rescue_fw),20m@471m(config),10m@491m(reserve1),10m@501m(reserve2)
[    1.037730] console [ttyS0] disabled
[    1.061720] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 12500000) is a 16550A
[    1.070796] console [ttyS0] enabled
[    1.107157] f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 24, base_baud = 12500000) is a 16550A

mcm-daemon is now starting up and seems working on /dev/ttyS1 (had to change in the .ini).

root@debian:~# mcm-daemon -df
mcm-daemon[3443]: Bind name to ls. 
mcm-daemon[3443]: Listen on ls for connections. 
mcm-daemon[3443]: Server startup success on port 57367
mcm-daemon[3443]: Try number: 1
mcm-daemon[3443]: mcm-daemon startup complete, going to FanControl mode
mcm-daemon[3443]: found 4 ata ports
mcm-daemon[3443]: setFanSpeed 50
mcm-daemon[3443]: Try number: 1
mcm-daemon[3443]: Returning 1 read bytes
mcm-daemon[3443]: Try number: 1
mcm-daemon[3443]: Read system temperature: 29 °C
mcm-daemon[3443]: Returning 1 read bytes
mcm-daemon[3443]: Try number: 1
mcm-daemon[3443]: Read fan rpm: 1241
mcm-daemon[3443]: system temp: 29 fan rpm: 1241
mcm-daemon[3443]: query disk 1 temperature
mcm-daemon[3443]: query disk 2 temperature
mcm-daemon[3443]: query disk 3 temperature
mcm-daemon[3443]: query disk 4 temperature
mcm-daemon[3443]: system tempOld: 29, temp: 29, fanSpeed: 50, fanRpm: 1241
mcm-daemon[3443]: setFanSpeed 50
mcm-daemon[3443]: Try number: 1

FINALLY! :)

Cool! Good works hmartin :)

And thanks for testing esion!

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



Edited 1 time(s). Last edit at 12/01/2017 03:40PM by bodhi.

Thanks for the help guys! :)

Any chance of getting control over the power LED or the display maybe?

I don't think mcm-daemon was originally intended to control the power LED.

It is however possible, since the commands are known:

char PLedOffCmd[]                       = {0xfa, 0x26, 0x00, 0x01, 0x00, 0x01, 0xfb};
char PLedBlueOnCmd[]            = {0xfa, 0x26, 0x00, 0x11, 0x00, 0x01, 0xfb};
char PLedBlueBlinkCmd[]         = {0xfa, 0x26, 0x00, 0x21, 0x00, 0x01, 0xfb};
char PLedBlueFadeCmd[]          = {0xfa, 0x26, 0x00, 0x41, 0x00, 0x01, 0xfb};
char PLedRedOnCmd[]                     = {0xfa, 0x26, 0x00, 0x14, 0x00, 0x01, 0xfb};
char PLedRedBlinkCmd[]          = {0xfa, 0x26, 0x00, 0x24, 0x00, 0x01, 0xfb};
char PLedOrangeOnCmd[]          = {0xfa, 0x26, 0x00, 0x12, 0x00, 0x01, 0xfb};
char PLedOrangeBlinkCmd[]       = {0xfa, 0x26, 0x00, 0x22, 0x00, 0x01, 0xfb};

Edit: actually I just tested these and they don't work, so I will have to check what I sent earlier to magically change the Power LED function.

Also there is an undocumented command in the Welltrend on the EX2100: TemperatureValue_SATA

Maybe this provides some information about the disk temperature from a sensor? It doesn't seem to be documented anywhere currently and I didn't investigate the response too much (also I have no SATA disks installed currently).

---

For the EX4100 LCD, I have no clue. I assume it's connected to the Welltrend, and if it follows the rest of WD design, then probably there is some daemon running in Linux to put data to the Welltrend to then put data to the LCD. I don't understand the purpose of the Welltrend since it just seems to be in the way with no added value...

If you can find the program in the WD firmware which sends data to the LCD, use strace on it and see what it's sending to the Welltrend.

esion: what's the model of fan in the EX4100? Unless it is the same as the EX2100, the maximum RPM is probably different. This means the fan RPM reported by mcm-daemon will be incorrect. It would be too easy if the Welltrend just reported the fan RPM directly...



Edited 2 time(s). Last edit at 12/01/2017 04:04PM by hmartin.

esion Wrote:
-------------------------------------------------------
> Thanks for the help guys! :)
>
> Any chance of getting control over the power LED
> or the display maybe?

Please remind me. How far did saschadd and I got regarding Power Off and Power LED?

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

Quote
bodhi
How far did saschadd and I got regarding Power Off

I just tested the "Power Off" command from the kernel patch on my EX2100. It doesn't stay powered off, just shutting off for about 1 second and then starting again immediately.

import serial
from time import sleep

port = serial.Serial("/dev/ttyS1", 115200, 8, "N", 1, 0.1)

def WritePktToSerial(port, data):
   assert len(data) == 7
   port.write(data)
   port.flush()

def ReadPktFromSerial(port, timeout=5):
    data = port.read(7)
    if data and len(data) == 7 and data[0] == "\xfa" and data[6] == "\xfb":
       return data

WritePktToSerial(port,"\xfa\x03\x03\x01\x01\x01\xfb")
resp = ReadPktFromSerial(port)
import binascii
print binascii.hexlify(resp)

Welltrend output:

Check_SYSTEM_Command=03
nick pwr off 1
phy data=01
phy dir=01
nick pwr on
Check_SYSTEM_Command=11
PwrOnCause=08

The restart command seems to work as advertised:

Check_SYSTEM_Command=03
Yosemite Uart test
nick 2222
nick pwr on
Check_SYSTEM_Command=11
PwrOnCause=02

Why can't WD just be consistent with their undocumented dodgy MCU?!

@bodhi
I think there was no progress on Power LED and proper Power Off. The system halts on shutdown but the mcu is still running. The Power Button does no shutdown or restart. Power LED keeps blinking.

@hmartin
For strace I would have to boot to stock, right?

Output of the mcm-daemon on telnet:

root@debian:# telnet localhost 57367
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
help
      DeviceReady  Tells the MCU, tht the device booted fully
       SetFanMode  set fan control to mode "auto" or "manual"
        GetFanRpm  Reads the fan speed from the MCU
      SetFanSpeed  set the fan pwm value to 0 | min ... max
       GetSysTemp  Reads the system temperatur from the MCU
       GetHddTemp  print harddisk temperatures
        PwrLedOff  switches the all power leds off
       PwrLedBlue  switches the power led to blue
  PwrLedBlueBlink  blinks the power led blue
   PwrLedBlueFade  fades power led blue
        PwrLedRed  switches the power led to red
   PwrLedRedBlink  blinks the power led red
     PwrLedOrange  switches the power led to orange
PwrLedOrangeBlink  blinks the power led orange
   ShutdownDaemon  stops the mcm-daemon
             help  shows this message
             quit  closes connection to daemon

SetFanMode, GetFanRpm, SetFanSpeed, GetSysTemp seem to work, all other commands do not work.

I just closed the box, but I might have time to look up the fan model tomorrow.

I remember now.

We just used "shutdown -h now" or "power off" to shutdown Linux. And then wait for 30-60 seconds and turn off power.

It is safe to do this, if you know your box Debian system shutdown before that time.

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



Edited 1 time(s). Last edit at 12/01/2017 04:32PM by bodhi.

@hmartin,

Quote

I just tested the "Power Off" command from the kernel patch on my EX2100. It doesn't stay powered off, just shutting off for about 1 second and then starting again immediately.

Perhaps you can try to pigyyback the mcmdaemon Power Off in /etc/init.d/halt?

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

@hmartin
Just a wild guess: Maybe you have to tell the MCU to stay off? Standard behaviour is to boot if there is power.

Quote
bodhi
Perhaps you can try to pigyyback the mcmdaemon Power Off in /etc/init.d/halt?

I don't understand what this would change. Can you explain why you think putting the command in halt would be different than just issuing it while the OS is running?

Unless I've completely misunderstood, the MCU brings the Marvell SoC out of reset. So unless the Marvell needs to set some GPIO signal to the MCU to indicate shutdown before it halts, I don't know what could be different about sending the command during normal operation versus halt.

Quote
esion
Just a wild guess: Maybe you have to tell the MCU to stay off? Standard behaviour is to boot if there is power.

Yeah, that's expected. But the question is what is the correct command to the MCU to ignore input power and leave the system off?

The Power Off command for EX2U doesn't appear to work on the EX*100 series. Which is why I was complaining that WD can't do anything right.

Unless someone can find the list of what PwrOnCause codes are?

Quote
esion
For strace I would have to boot to stock, right?

Yes



Edited 1 time(s). Last edit at 12/02/2017 12:42AM by hmartin.

> Unless I've completely misunderstood, the MCU
> brings the Marvell SoC out of reset. So unless the
> Marvell needs to set some GPIO signal to the MCU
> to indicate shutdown before it halts, I don't know
> what could be different about sending the command
> during normal operation versus halt.

We don't do power off during normal operation. There are quite a few things that need to happen before power off is issued, as the final step.

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



Edited 1 time(s). Last edit at 12/02/2017 03:56AM by bodhi.

Quote
bodhi
We don't do power off during normal operation. There are quite a few things that need to happen before power off is issued, as the final step.

Yes of course, but I wanted to test without modifying a bunch of things (like the kernel).

Are you saying that if I issue the PowerOff command to the MCU as one of the last things the kernel does before halting the Marvell SoC, I should expect a different result?

hmartin,

> Are you saying that if I issue the PowerOff
> command to the MCU as one of the last things the
> kernel does before halting the Marvell SoC, I
> should expect a different result?

It might. Usually we have either GPIO PowerOff, or non-GPIO PowerOff driver in the kernel that got invoked as the last action during shutdown. So mcm-daemon should follow that pattern. We don't know all the details such as hardware watchdog (if any?) or every aspects so it might help to do that.

IIRC, peacemaker or MM or someone in the Grand Teton thread has a poweroff patch, too. That was for non-GPIO Poweroff.

Besides, no kernel changes necessary if you add command(s) in /etc/init.d/halt.

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

Would it be as simple as adding FW_setenv to all the posted env and is this done in debian or at uboot interrupt ? So my guess from looking at the original thread that I need to back up nand and then flash with the uboot, is this correct from there I can upgrade to you latest release Bodhi?

Wrong thread sorry.