Reigning in the Gen2

Thank you kindly sir! I will assault it shortly.

Did somebody say zram? I second that in a big way. Zram would be great for the Gen2 and an absolute godsend to the Gen 1 units for some compressed ram swap.

I will try building for Gen2 first, so I can actually test my modules after building them.

I dont have a Gen1 to test on, but I can also pull gen1 gpl sources for the latest available firmware (Not the bleeding edge ones, they dont have gpl source up yet, and because these are kernel modules, THE KERNEL MUST MATCH, no exceptions!) and try building them. If you have a Gen1 and feel like testing them, I can maybe hook you up. We will see. Depends on how successful I am building Gen2 sources. (Need to be sure my build env is set up right for this source package.)

If I am successful, it would be something that @fox_exe could bundle into a native application, but be aware that on firmware upgrade, the modules would need to be updated! Packaging into a native application would be useful for creating a dashboard control to set zram size, mount / unmount the swap from zram0, check compression ratio, etc. (easily done by querying the entries in /sys/block/zram0 after loading the needed modules. insmod lets you specify where the module to load is located, so this is totally doable I think. Just that web dev is outside my skill set, so building the gui goodies is not for me.)

Best way - Use OMV or Nas4Free (FreeNas?) and just add few modules for support our device (+ Module for cloud access).
Too many work for one man.

Wierd_w- I’d be glad to test a zram module for Gen1 if you manage to build one. The Gen1 unit I’d be testing on is on v04.04.03-113 firmware with a 3.2.26 kernel. Here is a link to the sources for that version. It needs to be staying on that version for now (because automatic Safepoints became broken in later versions and supposedly taken out of the latest firmware) so it also avoids the upgrade caveats you pointed out.

Most people interested in zram probably won’t expect GUI goddies with it. I sure wouldn’t.

In addition to that link one can also find direct download links for the previous GPL firmware and WD released firmware downloads in the following thread:

https://community.wd.com/t/wd-my-cloud-v3-x-v4-x-and-v2-x-firmware-versions-download-links/148533

Ok, I successfully build and installed the needed modules for zram on gen2.

those are zlib.ko, zsmalloc.ko, and zram.ko

zsmalloc needs a tweak to its Kconfig to turn it from a boolean to a tristate, or else you cannot build it as a module. (checked upstream to be sure it can be built as one first)

I am going to try actually allocating a zram disk, and using it now. If I am successful, (you have no idea how hard it was to make their cross compiler work. Their build scripts stomp ALL OVER the path variable, which breaks everything. You have to modify them to be sane before you can use them. Morons! Given the quality of this build chain cough, I feel it necessary to fully test the module rather than just accept successful integration) I will build for Gen1

–EDIT

Nope, the old staging drivers in this kernel sources package is buggier than a bowl of mealworms. System hangs shortly after trying to write to the freshly created block device. I am going to try compiling a newer version of zram.c and zmalloc_main.c against this kernel tree. Will walk up the commit logs until I find appropriate patches to get these out of staging, then cross my fingers.

I know, there is the whole uboot process, where it initializes its ram, checks the flash area, sets some SoC specific variables for the board, and all kinds of fun stuff.

But I think I mentioned that I do not want to go that far up the chain, when I said I had no interest in mucking with the kernel image or the initrd, because I dont want to brick the device.

(embedded devices like this tend to use digital signature checking on kernel images and initrds, and get … cranky… when they dont get what they expect. Keeping all that intact, and just grabbing control further down is safer.)

This is true-- I DO have the appropriate cable for this though, and do know how to attach to it. I just dont want to shred the case off unless I really have to.

Do you know anyone that has the UART connected to a gen2 and that works?

I have done this many times with other embedded devices. Assuming they implemented the posts (and I dont have to go in there with solder to add them-- I really hate it when oems do that.), I have the necessary 3v FTDI to USB serial cable to connect with this UART and listen without much pain. I have a multimeter, and can find which is the tx, rx, and gnd pretty easily.

So no. But I can do this myself.

Reading the dmesg output of the device indicates that there IS a UART, and that the kernel takes possession of it in the boot process.

[    0.000000] Kernel command line: root=/dev/ram console=ttyS0,115200

Yes there is a UART on the Gen1 and Gen2. I’ve hooked up the Gen1 with no problem.
But when I hook up the gen2 I get no output. Not sure why.

Does it have hardware cls? It might be more than 3 wire serial. Might be 4 or 5 wire. How many posts are there? (it might have independent grounds for rx and tx as well, so that while it is raising its tx high, you are not getting conductivity because the gnd you are connected to does not close the circuit. You might need jumper wires to connect the grounds together so your cable works.)

If the device (mycloud) uses isolated grounds for tx and rx, you will need to put a jumper wire between the grounds though. Otherwise your cable (which expects common ground) will only be able to talk, or listen, depending on which one it is connected to.

Just grasping for a possible explanation for why he was able to successfully connect to gen1, but could not listen to gen2.

I thought that I had a picture of pin-out. But I can’t find it. It is 4 pins tx rx gnd and vcc.

Do you get anything at all? More importantly-- do they provide posts? (I have joint damage, and soldering is something I have difficulty with these days.)

(now tempted to abandon attempting to patch newer zram into provided kernel source, and take cover off to see if I can read the uart.)

*takes apart, looks

NOPE. NOT POPULATED. Cheapskates. Really, is 1/2 a cent per unit REALLY worth this? I would gladly pay the extra half cent per unit to not have to stabilize my soldering iron with a freaking armature due to my joint damage, just so I can connect to the debug port you DESIGNED the system to have, OK? Yes-- I would gladly pay it. I would pay it for 100 other people too.

No posts. Just edge connector. But the connectors very close together. I’ve looked into
taking an old post connector and cutting off three posts and solder them to make a removable connector.
Was just waiting to see if anybody had a suggestion on why it didn’t work.

Fox has pictures on his site but I currently cant connect to his site.

Looking at the connector positioning, it looks like it will be something like this:

gnd, tx, rx, (gap) vcc

but that is just a guess. I dont feel like messing with it, because I really dont want to have to solder those damned posts on. You have no idea how it hurts my hands to do that.

Instead I will just continue trying to port zram and zsmalloc from a newer 3.10.x source tree in. (one where it is not in staging)