Thank you.
I have tried the version 2.0 of the guide since the OP has stated that Guide 1 is for a 1TB or 2TB MBL.
Should I try version 1.0 of the guide now?
Remember I have the 3TB MBL and I am not sure if the version 1.0 guide would even work with that model.
whoops, should have been this link
The full debrick.sh script with the DESTROY command cares not what size HDD you have, it wipes the partitions, rebuilds them, sets up the MDADM array and writes the extracted rootfs.img to it. My fiddling MBL was originally a 1TB, its been a 640GB,1,2,3,4,6 & 8TB with that script.
It will also happily write your MBL with the latest/last firmware so there’s one step that’s not needed.
Ok. I see you have posted the same link again.
But, since I really have nothing to lose at this point in time with the disk and the device in general, I can attempt to use the version 1.0 of the guide with the included debrick.sh and see how that goes.
I am not sure what is the difference between the 2.x firmware and the 1.x firmware.
My device here is the 3TB MBL. So I assume it is 2.x firmware, but I could be wrong.
Likely just a couple years of security and feature updates.
Makes no difference. Just like the 1 & 2TB, the 3TB started with v1.xx before the 2.xx versions dropped. I’d avoid running any older firmware if at all possible, hence this thread with amazing @Ewald doing amazing things and persuading an updated Linux to run on the MBL which hopefully has addressed the last 6 years of security patches.
I updated my experience here:
The dashboard show initialising all the time, device seems very slow and a couple of factory resets have not helped. Ssh worked just once and now it is not working.
Firmware upgrade is also failing.
I tried to compile the kernel using both Gentoo-Sources and Vanilla-Sources in Gentoo (kernel 4.9.134), but I am still getting this error:
CC drivers/ata/sata_dwc_ncq.o
drivers/ata/sata_dwc_ncq.c: In function 'sata_dwc_isr':
drivers/ata/sata_dwc_ncq.c:760:17: error: '_3G_BLINK_NO' undeclared (first use in this function)
signal_hdd_led(_3G_BLINK_NO, _3G_LED_RED);
^~~~~~~~~~~~
drivers/ata/sata_dwc_ncq.c:760:17: note: each undeclared identifier is reported only once for each function it appears in
drivers/ata/sata_dwc_ncq.c:760:31: error: '_3G_LED_RED' undeclared (first use in this function)
signal_hdd_led(_3G_BLINK_NO, _3G_LED_RED);
^~~~~~~~~~~
drivers/ata/sata_dwc_ncq.c:913:31: error: '_3G_LED_OFF' undeclared (first use in this function)
signal_hdd_led(_3G_BLINK_NO, _3G_LED_OFF /* no color */);
^~~~~~~~~~~
drivers/ata/sata_dwc_ncq.c: In function 'sata_dwc_bmdma_start_by_tag':
drivers/ata/sata_dwc_ncq.c:1195:17: error: '_3G_BLINK_YES' undeclared (first use in this function)
signal_hdd_led(_3G_BLINK_YES, _3G_LED_GREEN);
^~~~~~~~~~~~~
drivers/ata/sata_dwc_ncq.c:1195:32: error: '_3G_LED_GREEN' undeclared (first use in this function)
signal_hdd_led(_3G_BLINK_YES, _3G_LED_GREEN);
^~~~~~~~~~~~~
drivers/ata/sata_dwc_ncq.c:1131:6: warning: unused variable 'statusIntr' [-Wunused-variable]
u32 statusIntr, reg, ch_en, dma_en_ch, __iomem *dm = &(hsdev->sata_dwc_regs->dmacr);
^~~~~~~~~~
In file included from drivers/ata/sata_dwc_ncq.c:21:0:
drivers/ata/sata_dwc_ncq.c: At top level:
drivers/ata/sata_dwc_ncq.h:467:20: warning: 'sata_reg2txt' declared 'static' but never defined [-Wunused-function]
static const char* sata_reg2txt(unsigned int id);
^~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:297: drivers/ata/sata_dwc_ncq.o] Error 1
make[1]: *** [scripts/Makefile.build:547: drivers/ata] Error 2
make: *** [Makefile:1008: drivers] Error 2`
Any ideas on why it would be failing the compile? I am using the .config with the patches.
it is great . i want to try .
@Simba7,
This is due to the latest kernel I posted (4.9.119) which is now enabling hdd activity led.
One of the patches did not properly apply, not entirely sure why, maybe some bad character. I uploaded a new version of the patch set here. Alternatively, you can just fix the one file that did not get properly patched using this single patch with the command “patch -p 1 -b -i 003b_enable_leds.patch”
Tested on 4.9.135.
Sorry for the inconvenience,
Ewald
It works great! I really like the activity LED so I know when it is busy.
Hey, no gripes here. If it were not for you and kl_yang, we’d be stuck on 2.6.32 forever. There’s still quite a bit of life left in these “old” MyBook Lives.
The only MyBook that suffered this fate was a MyBook World Edition II (darn OX810 processor). It’s stuck on 2.6.24.4 until someone figures it out or they release the documentation (good luck).
I’m off recompiling Gentoo on these three (1TB, 2TB, and 3TB). It’s been years since they have been updated, so I am rebuilding from scratch (I do a Stage1 from the device itself), which should take a week or two due to the processor.
Hi Ewald, Simba and KL Yang,
I’m working to port the sata_dwc_pmp driver to 4.18 but I’ve hit 3 bricks along the way. One was a timer refactor which I got past. Second was a change in dma-mapping.c which I easily reverted. The 3rd one has got me stumped. I’m think I’m getting a null pointer passed into map_sg_to_lli() . I am just now seeing that Net Console needs a patch to work so I will try that (because right now I have read only UART access).
Has anyone else tried getting past kernel version 4.14 yet?
@goldstar611,
I am working on 4.14. This is a major release and unfortunately there are bugs for older HW, likely because less and less developers are testing on older HW. Fortunately the OpenWRT/Lede teams has fixed things many both upstream and with patches. They have a working 4.14 kernel that works on mybook live.
Their patch list is quite impressive… I am pushing the HW a bit more than the OpenWRT team and hence we are hitting an extra layer of defects. With the latest 4.14 versions (65+) things have improved, but still, my current code is unable to survive a 12 hour torture test 
Also performance-wise, it’s a mixed bag. Hence, I have temporarily paused the work on 4.14 and did some Samba and splice tuning with dma engine.
Did you start from my sources ? I am happy to look at your code and compare to my 4.14 work.
Ewald
Reading and writing u-boot environment flash from Debian Jessie
Recently I was playing with boot from TFTP and u-boot image fallback in the case a boot image fails to load.
This would avoid the need to open the Mybook Live shell in case of some boot failure and e.g. expect or (low-level) format the embedded hard drive without the need to take off the enclosure ! For example, if u-boot fails to boot from harddisk it could fallback on TFTP/BOOTP boot using kernel with ramfs that has sufficient tools on board to diagnose the hard disk inside.
One of the requirements to make this all work is the ability to read/write the u-boot environment stored in nor flash from the OS, which is stored within /dev/mtd0.
First install u-boot-tools:
apt-get install u-boot-tools
Then create /etc/fw_env.config:
cat >/etc/fw_env.config <<EOF
/dev/mtd0 0x1e000 0x1000 0x1000 1
/dev/mtd0 0x1f000 0x1000 0x1000 1
EOF
Now you can check your environment: fw_printenv
And set a variable: fw_setenv variable value
In this way a running operation system can feedback to u-boot that booting has successfully completed and there is no need to try a fallback boot image 
Ewald
I get a good boot from HDD everytime!
I went for straight TFTP boot every time for uImage and apollo3g.dtb. Just need to copy boot.scr once to the MBL and keep your TFTP server running / up-to-date while developing.
IP address and rootfstype will probably need adjusting
boot.cmd
echo Boot from U-boot configuration, load uImage and device tree over tftp
setenv ipaddr 192.168.0.160
setenv serverip 192.168.0.42
setenv md0_args ‘setenv bootargs root=/dev/sda1 rw rootfstype=ext3 rootflags=data=ordered’
setenv load_tftp ‘tftp ${kernel_addr_r} uImage; tftp ${fdt_addr_r} apollo3g.dtb’
setenv boot_tftp ‘run load_tftp; run md0_args addtty; bootm ${kernel_addr_r} - ${fdt_addr_r}’
echo ==== Loading Linux kernel, Device tree, Root filesystem ====
run boot_tftp
Yes, absolutely a great solution. When the kernel fails to load, you only need to replace the uImage on the TFTP server. That was the solution I was using until I started to encounter (once and a while) issues with working kernels that were failing over TFTP, specifically with 4.14+. Probably an initramfs error on my side.
Here is an alternative for those of us that are a too lazy to fix things by hand …
boot.scr
setenv nc ‘setenv bootdelay 10; setenv stderr nc; setenv stdout nc; setenv stdin nc’
setenv ncip 192.168.1.20
setenv ipaddr 192.168.1.6
if itest -z “${boot_count}”; then setenv boot_count 0; fi
if itest ${boot_count} == 0; then setenv boot_count 1; else setenv boot_count 2; fi
saveenv
run nc
setenv boot_args ‘setenv bootargs netconsole=6663@${ipaddr}/,6664@${ncip}/3c:a8:2a:84:b6:37 root=/dev/sda2 earlyprintk rw rootfstype=ext4 rootflags=data=ordered’
setenv load_sata1 ‘sata init; ext2load sata 1:1 ${kernel_addr_r} /boot/uImage; ext2load sata 1:1 ${fdt_addr_r} /boot/apollo3g.dtb’
setenv load_sata2 ‘sata init; ext2load sata 1:1 ${kernel_addr_r} /boot/uImage.safe; ext2load sata 1:1 ${fdt_addr_r} /boot/apollo3g.safe.dtb’
setenv boot_sata ‘run boot_args addtty; bootm ${kernel_addr_r} - ${fdt_addr_r}’
printenv
if itest ${boot_count} == 1; then echo “=== Loading Default Kernel ===”; run load_sata1; else echo “=== Loading Recovery Kernel ===”; run load_sata2; fi
run boot_sata
Then add to /etc/rc.local:
# Reset boot_counter after successful boot
fw_setenv boot_count 0
Of course, you can use the same technique to alternate between booting from disk and booting from TFTP, or provide three booting options.
Are you using initramfs for booting off TFTP?
Ewald
Thanks for posting your boot.cmd! This actually could be really great for automated testing since the OS could know what commit it just compiled and booted from and if that was a success or not. I need to sit and thing about that algorithm though for a moment however.
Are you using initramfs for booting off TFTP?
No initramfs here. I’m not sure what I’d put there to be honest. The OpenWrt guys create /dev/null, /dev/zero, etc in their initramfs but there’s an option in the linux kconfig to provide a “fully functional /dev” and that seems to work great IMO.
Are you referring to CONFIG_DEVTMPFS? I have that in my kernel config, but I am unable to boot TFTP without initramfs. Perhaps I removed a config parameter too much in my attempt to compensate for the ever increasing kernel size :-(. Maybe you can post your config file so I see the difference…
Ewald
Ok I had to google this. It seems that CONFIG_DEVTMPFS is only 1/2 of the solution:
In the answer at udev - How to populate /dev directory when building my own initrd? - Unix & Linux Stack Exchange
the answer to your question is actually really really simple.
- Enable
devtmpfsin the kernel (CONFIG_DEVTMPFS=y)- Run
mount -t devtmpfs none /devas the very first thing in yourinitscript.
… You don’t even need to pre-populate/dev(in the initramfs image) with the basics likenull,zero, orconsole.
And here’s the confirmation for myself:
$ grep -r “devtmpfs” /etc
/etc/mtab:devtmpfs /dev devtmpfs rw,relatime,size=127232k,nr_inodes=7952,mode=755 0 0
I should also say that these are rules/values that buildroot added for me and that I’m running busybox for pretty much everything except the shell.
I had the good fortune to see this thread early on after a debricking adventure.
as far as I can remember Ewald provided a built kernel image and /lib/modules
which I used to get going again with much better performance. amen.
I think I then did a partially successful upgrade to jessie in situ
and my non-cloud MBLD
still ran with the old WD scripts. I was happy with that and it’s been
serving up movies and music the last year that it stumbled on
before. big thank you for Ewald’s and kl_lang’s work.
but it’s fallen over again!
I hooked up the disks to another linux system and found no log clues
to the reason, but the disks appear to be fine.
I would like to take the opportunity to go to a higher kernel with
netconsole support.
is anyone out there willing to make available a bundle of their
netconsole kernel image and modules (dtb files too?) ?
cheers me dears…
I can compile Ewalds 4.9.119 source that he mentioned above without much issue. Unfortunately I’ve recently lost everything related to this topic (and more stuff I havent used for many years but that’s not relevant)
Looking further into the future, upstream support is getting better and better because of the OpenWrt guys like chunkee. I have no comparisons in performance however, but can confirm that 4.18/4.19 “works” 
Update: It’s compiled and I have tested it over TFTP boot.
File name: install_4.9.119.zip
md5: d1098e0c100ce8686b843809e26b51bb
sha256: 15a983d99cf58a3b4e1885681d93c5b0b4c0f7fb4d14e0b1b3e4994900df45a8
Link: https://drive.google.com/file/d/1wnaELVEACd_QZjXebz7576dGWRH7trMF/view?usp=drivesdk
@IOdev,
Earlier in the thread I posted a fully patched Debian Jessie 8.11. It’s has many patches backported from Jessie 9.x since Debian has stopped support for our PowerPC.
Debian Jessie 8.11
Debian Jessie 8.11 optimized for MyBookLive:
- Debian 8.11 with security patches backported to PowerPC
- MiniDLNA (e.g. for access from Smart TV’s)
- Rsync 3.1.3 modified to use Kernel Crypto API
- Libkcapi + executables (Kernel Crypto API access from user space)
- packages to compile and profile kernels
- kernel 4.9.99 pre-compiled, updated DTB
- SAMBA patched for performance
Installation instructions here
Compressed tar archive here
It has an optimized kernel 4.9.77, which you can overload with any more recent version, either pre-compiled or from source + patches.
Ewald
1 Like
