fvdw-sl on WD My Cloud

[matt_max]

I think you both missed my post: viewtopic.php?f=4&t=3635&start=40#p36992

I read you post but I do not know what file are you referring to. That .config file is used to compile kernel?

[Mijzelf]

The stock kernel can't execute most binaries which are compiled for armv5/armv7, due to an incompatible memory scheme. One striking exception is the Debian version which is stock on that WD box. I was able to chroot it on my ZyXEL NAS540, but it's predecessor and successor couldn't. Don't know why that Debian version is an exception.
It is possible to build binaries for that kernel, by applying some linker flags (which I can't remember at the moment).

And yes, that .config is the kernel .config. I believe Mindspeed provided an SDK for that SoC, where the OEM could choose between 64k and 4k page sizes. 64k has as advantage that it's theoretically faster, as less memory management overhead is needed. But the disadvantage is that you are wasting more memory, and the number of available pages is also limited.
I think ZyXEL initially choose for 64kB pages, because of the filesystem size. An ext3 filesystem can handle at max 2^32 blocks. For some performance reason a block has to fit in a page. So with 4kB pagesize the size of an ext3 volume is limited to 16TiB. On an 4 disk NAS that is rather limiting. With 64kB pages the limit is 256TiB. Theoretically ext4 shouldn't have that 2^32 limit, but the implementation for that (more addressable blocks) was around kernel 3.2. I'm afraid this kernel is just too old for that. (Maybe only for Arm).
There must be other disadvantages for 64kB pages, as ZyXEL dropped them after about 2 years. Maybe the only reason was that they had meanwhile introduced another Armv7 NAS based on a Marvell Armada, and they wanted to share the packages.

BTW, I have read about that WD box that some people had problems to mount the data partition on another Linux box, which was caused by a blocksize >4kB. So maybe WD also had boxes with >16TB storage space? Which could be the reason to use 64kB blocks. Anyway, in case you (or another reader) ever has this problem, the remedy is to use a fuse implementation of ext3.

[fvdw]

@mijzelf so recompile the kernel with 4kB pages so make it possible to use armv5 binaries?

[fvdw]

I also found a debian package for wd mycloud gen1, we can also try to use that

[Mijzelf]

@mijzelf so recompile the kernel with 4kB pages so make it possible to use armv5 binaries?

Yes.

I also found a debian package for wd mycloud gen1, we can also try to use that

The stock firmware is based on Debian. (Squeeze?), and I think I remember that it contained original Debian binaries. I was trying very hard to get additional firmware running on my NAS540, back in 2014, and after I got a toolchain working, I found that this Debian could be chrooted. And I still don't know why. I *think* most binaries don't work because the sections in the binary are aligned at 4kB. The loader tries to set the executable flag for the pages containing executable content, and that fails when it's not 64k aligned. Yet the error is not very descriptive, just Killed.
Gdb doesn't provide more info. It took me a serious amount of time to find out what the actual problem is.

[fvdw]

thx mijzelf clear. Later I will have a look to the config of the debian kernel that I found, this in case my own kernel is not working :mrgreen:

I recompiled the wd gpl source kernel with 4kB pages, I had to didable the usb dwc_otg driver as it gave errors during compile but that is for later concern. Lets first see if this kernel can execute our binaries

@matt_max
Can try the attached kernel (dd to /dev/sdb6 of course unpack zip file first)

I am not sure if now the wd root file system binaries have a problem.

[matt_max]

New uImage is on my sda6 partition (sda5 still empty) - output from console. Still hangs on T0 (getty).

[fvdw]

there are many errors like this
sysfs: cannot create duplicate filename '/module/libata

the kernel tries to register again these files , why ??

Well the the compiler is running for another kernel I copied cpu and mem setup from a debian kernel of which they say can be run on this device.

Attached this debian kernel, while compiler is running you could try what this kernel does. If that one loads and runs my new kernel *should* run also

[fvdw]

compiler is ready

attached uImage-3-2
This kernel has (almost) same setup as the debian kernel

I also attched the kernel modules and firmware., see lib-config-3-2-archive.tgz
This must be extracted in root (/) of root file system
Because we have a different kernel the modules to be loaded should be updated as well as otherwise they may not work properly or even do not load

[matt_max]

@fvdw Correct me if I'm wrong - I need to:

• copy attached uImage to /dev/sda6

• extract attached lib-config-3-2-archive.tgz and just copy its content to /dev/md0 right?

What about kernel-debian.zip :scratch Copy its content to where? To /boot on /dev/md0?