H96 Pro+ S912 Standby mode

Well i used compiled version and YES i used h96proplus_v2_2 u -boot.

By the way, doing this i got wifi working after wake up from suspend state:

https://forum.libreelec.tv/thread/524-s905-builds-general-discussion/?postID=40599#post40599

1 Like

@derknut @bumerc
With the last commit the external RTL8211F is up and running in u-boot:

Now you need to set the wol mac end enable the chip when enter suspend. This is done like the set_wol in cmd_kbi:

#include <common.h>

#define MAC_LENGHT 6

static void set_wol(int enable)
{
char cmd[64];
int mode;

if ((enable&0x01) != 0) {

int mac_addr[MAC_LENGHT] = {0};

run_command(“phyreg w 0 0x1040”, 0);

run_command(“phyreg w 31 0xd40”, 0);
run_command(“phyreg w 22 0x20”, 0);
run_command(“phyreg w 31 0”, 0);

  char *s = getenv("mac");
  if ((s != NULL) && (strcmp(s, "00:00:00:00:00:00") != 0)) {
  	printf("set mac for wol = %s\n", s);
  	int i = 0;
  	for (i = 0; i < 6 && s[0] != '\0' && s[1] != '\0'; i++) {
  	mac_addr[i] = chartonum(s[0]) << 4 | chartonum(s[1]);
  	s +=3;
  	}
  } else {
  	printf("no mac for wol found\n");
  	return;
  }

run_command(“phyreg w 31 0xd8c”, 0);
sprintf(cmd, “phyreg w 16 0x%x%x”, mac_addr[1], mac_addr[0]);
run_command(cmd, 0);
sprintf(cmd, “phyreg w 17 0x%x%x”, mac_addr[3], mac_addr[2]);
run_command(cmd, 0);
sprintf(cmd, “phyreg w 18 0x%x%x”, mac_addr[5], mac_addr[4]);
run_command(cmd, 0);
run_command(“phyreg w 31 0”, 0);

run_command(“phyreg w 31 0xd8a”, 0);
run_command(“phyreg w 17 0x9fff”, 0);
run_command(“phyreg w 31 0”, 0);

run_command(“phyreg w 31 0xd8a”, 0);
run_command(“phyreg w 16 0x1000”, 0);
run_command(“phyreg w 31 0”, 0);

run_command(“phyreg w 31 0xd80”, 0);
run_command(“phyreg w 16 0x3000”, 0);
run_command(“phyreg w 17 0x0020”, 0);
run_command(“phyreg w 18 0x03c0”, 0);
run_command(“phyreg w 19 0x0000”, 0);
run_command(“phyreg w 20 0x0000”, 0);
run_command(“phyreg w 21 0x0000”, 0);
run_command(“phyreg w 22 0x0000”, 0);
run_command(“phyreg w 23 0x0000”, 0);
run_command(“phyreg w 31 0”, 0);

run_command(“phyreg w 31 0xd8a”, 0);
run_command(“phyreg w 19 0x1002”, 0);
run_command(“phyreg w 19 0x1002”, 0);

} else {
run_command(“phyreg w 31 0xd8a”, 0);
run_command(“phyreg w 16 0”, 0);
run_command(“phyreg w 17 0x7fff”, 0);
run_command(“phyreg w 31 0”, 0);
}
}

Then you have to check in detect_key function for the gpio: GPIOZ_15 or BOOT_8 (going from 1 to 0)
If 0 then wakeup by WOL. Manualy it is working fine - but I need help to implement the “set_wol” function…

That’s very good news. How did you test it, where you called set_wol()?
I would propose to write a new cmd module called “h96” or “wol” to setup the PHY. But I have no idea where to call it.
Thanks

set_wol needs to be called after entering the suspend mode. But this is not possible because it is a different task.
Also compiling does not work…

I started u-boot into console with the last commit.
Entered by hand line for line into the console to setup the RTL8211F.
This brings the PEMB pin high and the chip is waiting for a magic packet.
If a packet got received the hardware pin goes low.
Then the endless while loop detect_key in pwr_ctrl.c have to check the gpio and start the wakeup/resume.

The problem is also when the linux kernel starts the RTL8211f registers are getting modified so the wol would not work anymore. The set_wol have to be called again.
The only way I see right now is that the linux kernel setup the chip for wol and u-boot is checking the gpio for wol wakeup.

That’s sound promising and is the regular “Linux way” to activate WOL by “ethtool”. I will check the Linux part. Alternative it may be possible to add a quick and dirty hack to pwr_ctr.c to send MDIO commands to the PHY without a driver.

@derknut WOL is working now:


Use the commit “check for RTL8211F PMEB interrupt by Wake-on-Lan packet” only if you included first the linux kernel pull request! Otherwise u-boot will resume immediately from poweroff/suspend.

I will write a how to enable the WOL to the wiki:


1 Like

@atomizasser you can do the following as a quick fix for wifi on resume

  1. Go to \\Configfiles\ and make a folder sleep.d
  2. Then in that folder create a file named 01-wifi-resume.power with this content:
#!/bin/sh
case "$1" in
pre)
# <do something on suspend>
;;
post)
# <do something on resume>
connmanctl disable wifi
sleep 5
connmanctl enable wifi
;;
esac

Hi @Portisch,

I’ve installed your latest u-boot (just like atomizasser) on my minix u9-h.
However when I choose to suspend it doesn’t work (it’s the same as before).

I’ve uploaded the debug log from the moment i pressed the suspend. Can I provide anything else that may help to give you an idea why it doesn’t suspend? It would be great if you could take a look :slight_smile:
Or maybe there is something else blocking the suspend?

Thanks in advance,

kodi.log (8.8 KB)

edit: I’ve installed u-boot_q201_v2.2_green_PCB.tar.gz following the wiki on the github

This is the patch to compile CoreELEC with WOL on the wired eth interface enabled:linux-010_rtl8221f_wol_S912_gpioz_15.patch (4.8 KB)
Just copy it to

CoreELEC/packages/linux/patches

and compile the image with

PROJECT=Amlogic DEVICE=S912 ARCH=arm make

After update of the CoreELEC system update u-boot:
Compile and update u-boot with the last commit:

After flashing enable the WOL for the wired ethernet interface:

@freshprince only a dmesg log will help. Also a uart log of u-boot would be nice. Try to contact @atomizasser because I do not own such a box.

Hmm strange it keeps spamming a message in dmesg.
See attachment
dmesg.txt (17.6 KB)

Thanks a lot for the patches and info. Is there a shortcut to only build and replace a kernel/modules?

CoreElec build is running, but on my machine this seems to be a “long term solution” =;-)

@derknut https://mega.nz/#!WeA0zKZJ!HvhAah8M95BnBfQB_gcDxmNsT8wEmiXCWdElR8MmiQU

i did nothing special
After update the u-boot following guide, i activated suspend mode as guide said. Restart and test suspend mode; i got green light in minix box. Then i tested to wake up from HDMI CEC and worked great.
The only missing was WIFI module, but after following @anon88919003 suggestion, wifi was working again after wake up.

1 Like

@Portisch : Thanks a lot for the image, but unfortunately WOL is not working at my H96 Pro+. Even in standby mode the ETH link is off at my switch, PHY seems to be down.
I am wondering why I cannot read the DTB WOL status:
# hexdump /proc/device-tree/ethernet@0xc9410000/wol
*
With my first “home brewed” CoreElec image I will try to debug.

Thanks for any hint

Try fdtget if wol = 0 or 1: fdtget /flash/dtb.img /ethernet@0xc9410000 wol
Does fw_printenv mac show your mac address?
What does dmesg | grep wol show?
Every command is working only for CoreELEC on SD card!

@Portisch
Thanks a lot for your support, now it is working.

I am not sure what was the problem, but if I created a completely new SD card with release version, update to your image and u-boot and follow your WOL guide. I got this message at suspend:
set mac for wol = 78:c2:c0:...
The ETH link keeps active in “standby” and “power down” mode and
sudo wakeonlan 78:C2:C0:....
starts the device.

I will now update step by step my eMMC installation.

Very good work, thanks again.

P.S.: How I can create just a kernel with my changes, e.g. add printk for debugging? I tried
PROJECT=Amlogic DEVICE=S912 ARCH=arm ./scripts/build linux
but the changed kernel is not recompiled. The “clean” script deletes the complete kernel source including my changes. I am also confused about “ARCH=arm” for a “aarch64” target.

Drop a xxx.patch file in /CoreELEC/packages/linux/patchs and recompile as normal. Then the linux-amlogic is getting purged and recompiled.

Sorry for bother you again, but I have still difficulties to bring up WOL with eMMC boot. Using the same Kernel/U-Boot and DTB I cannot see “set wol” at dmesg. Is eMMC boot using a different DTB?
Thanks a lot for any hint
derknut

@Portisch I just installed the working SD card to eMMC and WOL is working. Thanks a lot for your support