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.

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 ;-)

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.

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...

@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.

Quotebodhi
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.

Quoteesion
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 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.

> 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.

Please, enter the code that you see below in the input field.
This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right.
If you enter the wrong code, a new image is created and you get
another chance to enter it right.