the file that you need to look up on the kernel sources is “cmd_boot.c” it has all the info about how to read the fwtable, i believe these lines (probably) are the important ones, but i have not knowledge about programming:
I am not really a C-programmer either
Already looked at the file and decided that a proper compile would be best. I tried the accompanying toolchain on native AARCH64, Debian-WSL, Cygwin and a Debian-x64 but I couldn’t execute any of the binaries.
That is my current hold up
it only works on an x86-64 machine, is already configured for cross compiling, i recommend an Ubuntu 18.04 image (has libssl1.0-dev). But you won’t gonna find anything useful, unless that you decide to deactivate the bootloader checksum and change the bootloader. the bootloader sources make a dvrboot.exe file (the bootloader installer used trought UART) and several .bin files (bl31.bin, fsbl.bin, fsbl_os.bin, etc.) these files are the core components of u-boot, the only way of editing the fwtable.bin is understanding the boot file.
Hi all, I’ve spent a lot of time this week on the firmware. For the fwtable.bin partition (first partition), there are 3 parts: the FW desc table (32 bytes), followed by a part entries (48 bytes each) then fw entries (32 bytes each).
The FW desc table has : signature (8 bytes), checksum (4 bytes), version (1 byte), reserved (7 bytes), paddings (4 bytes), part_list_len (4 bytes), fw_list_len (4 bytes). Paddings is how much the bootloader will read from disk, so at least the size of the whole table (FW desc + parts + fws). Part_list_len is the size of the part entries, to get the number of entries divide the size by 48. FW_len_list is the size of the FW entries, same as above, divide by 32 to get the number of entries.
The part list is basically ignored on the Home, not sure on the Home Duo. Based on the code, the size of parts can be zero will still test. FW list is where the file pointers are, each entry has: type (1 byte), “options” (1 byte where first 6 bits are reserved, 1 bit for LZMA compression, 1 but for Read-Only), version (4 bytes), target_addr (4 bytes), offset (4 bytes), length (4 bytes), paddings (4 bytes), checksum (4 bytes) and reserved (6 bytes).
The target_addr is where in the RAM the file will be stored (e.g. kernels goes to 0x03000000, DTB at 0x01f000, etc. Offset is where it is on disk, divide by 512 to get the sector, look at the GPT partition table to find the matching partition. Length is the data size, Padding is how much to store in memory. Every type has a special meaning, look at the fw_type_code_t enum at bootloader/uboot/arch/arm/include/asm/arch-rtd1295/fw_info.h.
I do plan on writing a tool over the weekend to generate the fwtable.bin, I’ll post here if I get it done.
I’ve got MyCloud Home 8TB with firmware 7.8.0-112 - there is impossible to install Debian on it. I’ve tried files made by Fox_exe and from second source (WDNAS8). Both downloaded couple of times. Used 3 pendrives, format them few times with different programs (by Windows management service, by Disk Genius, MiniTool Partition Wizard, even by unetbootin - even with try of creating few partitions and storing files on all of them. The device is starting with fast blinking led, later (after ~20-30 seconds) led is dimming and shines steady light, and it’s all… Device sometimes lost connection with router, sometimes freezes. After reset there are no changes made.
I think, that WD in new firmwares block possibility to install alternative software. May someone more experienced than I check it and maybe find sollution?
Hi! Does anyone knows why the NFS doesn’t work or how to make it work? I trace it down to a kernel module not loaded (NFSD) but the kernel modules are not present
Salut, j’ai pas d’idée et un peu moins de temps: j’imagine que ça peut être les logs qui prennent pleins de place: faut trouver le moyen de changer le nombre de jours sauvegardé (mais aussi regardé pourquoi y’a autant de logs !) et limiter le nombre de Mo par log
You can install clean using files from chroot as @Alex-N mentioned above.
The image with OMV is almost full already and you need to cleanup the temporary files manually.
The original Kernel has everything it supposedly needs compiled in statically, hence no kernel modules. There used to be a user-space NFS daemon but I don’t know if that is still an active project. Mounting NFS only works with a kernel module.
I already compiled a new kernel but it only works when booting in rescue mode from USB.
For installing the kernel we need to figure out how to do the checksum calculation for the fwtable.bin, which @sgissi is doing.
Another option is to recompile uBoot without the need for fwtable.bin like @zeusjan seems to have accomplished.
The format is quite simple, I’m working on the utility. As for changing uboot, the Home has a 1Mb SPI flash with hardware settings, the 32-bit u-boot (which reads bootConfig partition and fwtable) and the 64-bits uboot (that we have no sources for). Replacing uboot is dangerous but would be great to get rid of bootConfig and fwtable.
The bootloader on the duo is on the emmc, I change it because messing with the emmc i kill the device. But yes is dangerous to change the bootloader. if i remember correctly all the sources are there (including uboot64) just that there is two versions of the sources, 6 and 4, one has the sources that the other dont had, but i dont remember correctly. Anyway, changing the bootloader on the home with 1 disk, i believe is even more dangerous, i dont know if it has a recovery method im case that you mess the SPI ( the duo has a recovery in case that you mess the emmc). So best and safest way is edit the fwtable, i dont know if you already see it (or even if is useful) but the installer of omv of the duo has an utility for editing the fwtable made by forth32, is a shame that he dont share the sources
I did copy it onto my rescue stick but it complains
/ # fwtutil --help
unable to open EMMC block device
It’s trying to open /dev/mmcblk0 first - I changed that string with a Hex editor to /devsataa1 and can run.
Obviously this doesn’t do any good since all other functions actually try to read the EMMC and only return empty lines
/ # ./fwtutil -l
**** Firmware list ****
## ro lzma version tg_addr offset length paddings checksum type
--------------------------------------------------------------------------------------------
* Total len = 00000000 Paddings len = 00000000 *
/ # ./fwtutil -p
**** Part list ****
type ro length fw_count fw_type mount_point
------------------------------------------------
As to writing uboot to SPI… I did that many times with other devices and wouldn’t be afraid of that (although you make the device unbootable if something goes wrong). On that note, did somebody already figure out the proper configuration of fw_env.config? What offset does the uboot config start?
Sounds like it is built for the Home Duo that has eMMC. I hope I can finish the tool by the end of the week, just hard to find free time
Edit: Adding to the SPI point. You can dump the SPI file from /dev/mtd0 to take a look. If all goes really wrong, you can physically clip the SPI flash and load it with the original data.
That because the fwtable from duo and your device are completely different. on the duo the kernel, dtb, rootfs, etc. files are stored on memory addresses directly on the first raw 115 mb of emmc. On your device they are stored on partitions inside the sata disk, so even if you change the target drive isn’t gonna work. I only mention that app because maybe isn’t very hard to reverse engineering it, but that is too much for me. By the way, you managed to compile the bootloader?
No, compiling the Bootloader gives some assembler errors. Haven’t found a machine where the cross-compile works
I already dumped the mtd0 partition containing the bootloader and the bootloader config. The problem is that the config is contained as a file inside the partition. the “fw_printenv” utility normally points at an address in the flash and I don’t know how to specify that in the config.
Going to wait for @sgissi to find some spare time for the fwtable tool
Hi all, sorry for the delay, it started as a small project and took over. If you want to test, you can download it from Release Initial Release · sgissi/wdmch-tools · GitHub . The library part is feature complete, the utility doesn’t manipulate parts yet, just the firmware entries.
It is not highly tested so proceed carefully. I recommend to dump the fwtable to a file (dd if=/dev/sataa1 of=fwtable.bin), manipulate with fwtablectl (e.g. fwtablectl firmware update fwtable.bin RescueKernel path/to/Image), check it is Ok (fwtablectl show fwtable.bin) and then flash it back to disk (dd if=fwtable.bin of=/dev/sataa1). To manipulate directly, use /dev/sataa1 as file (e.g. fwtablectl firmware remove /dev/sataa1 GoldAudio.
Source code is in Github (GitHub - sgissi/wdmch-tools: Tools for WD My Cloud Home), feel free to open issues or contribute. License is GPL as it is heavily based out of uBoot headers which are GPL. I will put more documentation of the format and the boot process in the Github Wiki.
