Alex-N - The memory settings worked, I just needed to delete the journal directory to stop all the console messages.
Right - read the whole thread again since most has been covered.
Did you try running in host mode? Maybe it’s some missing kernel module.
Btw. did you use the original .config file when compiling the kernel or did you run make menuconfig beforehand?
via menuconfig added modules. .config.zip before build kernel.
The interesting thing is that Docker works…
I return the old kernel 4.1.17 and Portainer starts working.
Where to read what modules are needed, and then everything was already tired by the method of enumeration …
Hi @RAH-66, first of all, thanks for your great work on MCH. I have a My Cloud Home Duo and I tried to sucessful installed Debian11+OMV6 based on your and other’s works(GPL_MCH_7.15.0-160_20210429). So far, everything goes fine except the Docker didn’t work. I’m not sure if any Kernel difference for MCH and MCHD, I think they are the same since the Kernel link from WD is the same.
I want to try your new kernel with KVM and newer, but as you know the MCHD has it own EMMC to storage kernel, so I can’t follow your guide to update the new kernel. Could you please hlep to provide the complete updated kernel file which been used in install stage, so I can try to make a clean install with newer kernel and see if the problem solved.
Sorry for my bad English, and thanks for the help in advance.
I can’t seem to get a stable system when altering the memory settings.
When I try to disable all the ION related stuff along with the SOC specific RPC and codecs, the kernel doesn’t compile 
I had to patch the dts again to get the LED working.
Good news is that the watchdog driver is now using proper /dev/watchdog devices adressable by the linux watchdog daemon.
I am currently looking into the kernel command line in the uBoot MTD in order to make systemd use cgroups v1 only … hopefully this fixes @RAH-66 docker issues.
It looks like you go faster than me, for what i found we need to add “systemd.unified_cgroup_hierarchy=0” to the boot arguments to solve the docker problems with the new kernel, you don´t need to edit the uBoot, yo can edit the kernel and force the commands that you want, is safer.
Update!: it works, now docker and portainer are working again.
2 Likes
Hi, Could you help to provdie the .bin file for Kernel and DeviceTree, so that I can use the fwtutil tools to update emmc component for My Cloud Home Duo, thanks.
I tried adding that to the kernel command line in the dts.
Didn’t know that it can be added to the kernel config 
The research into the uBoot params is more of an explorative project 
1 Like
Yes, it works… and it seems adequate at first glance, but if you try to create a new kernel, it reboots the device at the very end of the kernel compilation, when the vmlinux.o process is running. I looked through the UART, it does this after ~ 20-30 accesses, apparently it starts to consider the kernel assembly as a hung application. Maybe this is also a “joke” from WD/Realtek
I don’t know your device (DUO), you need to consult zeusjan. To be honest, I’m very surprised how my assembly could run on your device, these are technically different models, even starting with the (Home) RTD1295 / RTD1296 processor (Home DUO), eMMC e.t.c.
For now I deactivated the watchdog, is in the correct path, but systemd doesnt recognize that a watchdog exist (the same with zram, and other oddities of Debian11), if you want to activate watchdog, you can use the script from Alex-N blog, and change the path to /dev/watchdog, I check that the watchdog work sending “touch /dev/watchdog” every minute, and it works perfectly, the problem is Debian and systemd, the watchdog daemon refuse to load unless you load the external module, or edit the daemon itself.
If you are curious, It works from one device to another, the problem is that if you use the one drive bay kernel on the duo, you didn´t had the second disk available, the emmc or the fan (and other problems that i don´t remember), i know it because when there wasnt´an OMV installation for my duo, I manage to boot my device with forth32 recovery for the single bay, and then I learned how to compile the kernel for my device.
I also tried on the dts, but in my device (Cloud Home Duo) the cmdline is fixed (you can change it with a serial connection interrupting the boot process), the edits from the dts only works when booting from usb. It´s that way because there is where the serial number is stored, I don´t know if it is the same on your device.
Thanks for the confirmation about the cgroupV1 requirement.
I now tried adding the entry to the kernel configuration but that didn’t work
Looks like the boot process is different as we don’t have an eMMC. In fact the bootargs for Monarch are stored in SPI flash.
Interrupting the boot process didn’t work as the timeout is set to “0”. Also this wouldn’t be feaseable for anybody else 
Weird, it must work because it passes all other arguments, you remembered to activate “Always use the default kernel command string”?, and check that the edit on “Default kernel command string:” stays after saving the .config, but i´m 100% sure that it must work because this commands changes the cmdline at boot.
Also you can check that the string is loaded with “cat /proc/cmdline”, if it´s loaded, then the problem is somewhere else (for example I forgot to activate overlay in the .config, and docker refused to work)
Very productive morning - I didn’t set the “always use the default kernel command string” 
Now Docker doesn’t complain about the cgroupsV2 settings anymore!
For zramswap you have to include LZ4 compression support in the kernel or use LZO alternatively.
The watchdog works for me using the Debian watchdog package and this config:
# Start watchdog at boot time? 0 or 1
run_watchdog=1
# Start wd_keepalive after stopping watchdog? 0 or 1
run_wd_keepalive=0
# Load module before starting watchdog
watchdog_module="rtk_wdt"
I have yet to compare the data transfer speeds.
Other than the memory constraints this kernel looks promising.
2 Likes
Thanks for the tip for watchdog, my transfes speeds are better than with the old kernel (about 50 MB/s because i´m using it over WIFI, but before i manage only 40), I already using zram instead of zswap with a little hack that I manage, but now i´m thinking changing to zswap (in theory is better???, don´t know if it´s truth), the only think i need to test is the HW video acceleration, now we have the codecs included in the sources, hope i manged to get it working in the following days.
Yes, the Kernel for MCH single bay seems working in MCHD but as you said the fans and another drive can not be found. I used a mixed combine with MCH kernel and MCHD rootfs (from forth32) to boot my device previously, and it works fine but only docker not work.
Awesome, thanks for the “systemd.unified_cgroup_hierarchy=0” info. That was my hold up on using the new kernel with Docker. 
1 Like
I found where they hid the 184MB + 12MB memory reserve for GPU (where else 60MB remains a mystery)
linux-4.9.266/include/soc/realtek/memory.h
line 209:
/* legacy : 184 M */
#ifndef CONFIG_RTK_TRANSCODE
#define ION_MEDIA_HEAP_PHYS1 (MEM_SLOT(0, PHYS, 0x00000400))
#define ION_MEDIA_HEAP_SIZE1 (MEM_SLOT(0, SIZE, 0x00000400))
#define ION_MEDIA_HEAP_FLAG1 (MEM_SLOT(0, FLAG, 0x00000400))
#else
#define ION_MEDIA_HEAP_PHYS1 (MEM_SLOT(0, PHYS, 0x00000400))
#define ION_MEDIA_HEAP_SIZE1 (MEM_SLOT(0, SIZE, 0x00000400))
#define ION_MEDIA_HEAP_FLAG1 (MEM_SLOT(0, FLAG, 0x00000400))
#endif
/* legacy : 12 M */
#ifndef CONFIG_RTK_TRANSCODE
#define ION_AUDIO_HEAP_PHYS (MEM_SLOT(1, PHYS, 0x00000400))
#define ION_AUDIO_HEAP_SIZE (MEM_SLOT(1, SIZE, 0x00000400))
#define ION_AUDIO_HEAP_FLAG (MEM_SLOT(1, FLAG, 0x00000400))
#else
#define ION_AUDIO_HEAP_PHYS (MEM_SLOT(1, PHYS, 0x00000400))
#define ION_AUDIO_HEAP_SIZE (MEM_SLOT(1, SIZE, 0x00000400))
#define ION_AUDIO_HEAP_FLAG (MEM_SLOT(1, FLAG, 0x00000400))
#endif
1 Like
Good find on the extra memory, I compiled linux-4.9.266 and it works great.
I tried the new zip - Install_usb_disk_Debian11(OMV6)(GPL_MCH_Monarch_8.7.0-107_20220623) and the makepartshdd.sh is using the old /dev/sataa and with your new USB Boot should be sda. Also, for some reason the new install will not recognize eth0 . No network initialization.
How did you get sda to work?
Thanks
