Welcome! Log In Create A New Profile

Advanced

How-To: Debian and U-Boot on WD MyCloud EX4100

Posted by eep 
Forum List Message List New Topic
eep
How-To: Debian and U-Boot on WD MyCloud EX4100
November 02, 2024 04:31PM

Last update: 24-11-2024

This How-To is a Work-in-Progress, and will be fleshed out over the next few weeks as I transfer my own notes compiled from the work of others on this forum (bodhi, hmartin, saschadd) as well as my own experiments with my EX4100.
================================================================================

DISCLAIMER:
  • No warranties / guarantees offered - continue at your own peril only if you can accept all risks
  • Read and understand all instructions and references
  • Back up all of your data (and verify you can restore from backups)

================================================================================

Breakdown:
  1. References and Links
  2. Rationale
  3. Software / Equipment Required
  4. Tips for saving a Session Log
  5. Backing up data on the NAS
  6. Accessing on-board UART
  7. Testing with kwboot
  8. Setup Debian rootfs for EX4100 on USB 2.0 flash drive
  9. Burn customized U-Boot on EX4100 NAND flash
  10. Set up EX4100 to boot from USB into Debian rootfs
  11. Configure Debian for EX4100 (necessary and helpful tweaks)
  12. Restore stock WD firmware / U-Boot

================================================================================
1. References
================================================================================


1.1 Instructions for installing on EX2100 by hmartin - highly accurate, but NOTE: use modern kwboot bins from Ref 1.2 below rather than the 2018 versions in the original post
https://forum.doozan.com/read.php?2,50769,50769#msg-50769

1.2: U-Boot flashing utilities and (modern) kwboot binary - the latest versions of kwboot have a terminal you can use, and will automagically patch NAND images to UART as required.
https://forum.doozan.com/read.php?3,27280

1.3: bodhi's Debian rootfs- links and install instructions
https://forum.doozan.com/read.php?2,32146

1.4: U-boot bodhi-tld-6 and patch (original hmartin/saschadd threads)
https://forum.doozan.com/read.php?2,34103,page=13

1.5: hmartin's photos of UART unpopulated UART header on EX2100/EX4100 from Ref 1.1:
https://imgur.com/iOYmXI4
https://imgur.com/PrTQO8C

1.6: Bodhi's Debian Rootfs for MVEBU (suitable for EX4100 and EX4100)
1.6.1: Main post: https://forum.doozan.com/read.php?2,32146,32146#msg-32146
1.6.2: Latest (as of writing) Bodhi's rootfs for mvebu direct link: 
https://bit.ly/3Tq9pTO
Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2
md5:
009d315ebc813868344ce9221bcc3c70
sha256:
50ceb6465c46399901ab52406e15fd6406d53ec9d682d066f9fe9a87f779077f
And remember to check the hash of what you download, as always.
1.6.3: Latest (as of writing) Bodhi's Debian kernel: 
https://bit.ly/3XUKPMP
linux-6.10.11-mvebu-tld-1-bodhi.tar.bz2
md5:
7ce8ecae1afc900de1bd795ddf63281f
sha256:
70b56e5ff0871bf4fafaaa66b8062cb8d55b58dacbc6035c15f7e02198f194e2
As always, please check the hash of your download!

1.7: My previous posts re: u-boot on EX4100, with some extra info and uboots and scripts attached:
https://forum.doozan.com/read.php?3,138181,138285#msg-138285

1.8: WD MyCloud GPL Sources and Firmwares:
1.8.1: Support page for EX4100 - has links for all precompiled stock firmwares , as well as their GPL sources
https://support-en.wd.com/app/products/product-detail/session/L3RpbWUvMTYxMTY2MDA4NC9nZW4vMTYxMTY2MDA4NC9zaWQvZlVyb1VkX0UyOWpSQkNzbXhQMW56UnNXTVpzY1o4SEdtNmdaS1U1bXhySFFsc2klN0VRVENnUnBOQjNYbGtuQ0pRRlF4c0pHV3BBcVlOTHJGa1J4JTdFQ3VIYmpYUThkQ2E5YXZhZ050VEZDQUJuZHN5eVVfV1FsMWRkZyUyMSUyMQ==/p/133#WD_downloads

1.8.2: Legacy FW release of the EX4100 GPL source that includes arm toolchain binaries as well as u-boot sources
https://downloads.wdc.com/gpl/WDMyCloud_EX4100_GPL_v2.41.116_20201117.tar.gz


================================================================================
2. Rationale:
================================================================================


Much of the WD NAS product line already runs a Debian-based Linux. Because these products are appliances, administration is "made-easy", and additional software is installed by specifically ported "compatible Apps".
Since virtually no one (including WD) maintains/supports these apps any more, the possibility to run secure and up-to-date "MyCloud Firmware" and continue to use 3rd-party-provided integrations (such as Transmission torrent client App on your NAS) no longer exists.
If you are tired of the limitations of WD's appliance, you may choose to install a full-fledged Debian, and do all of the management yourself, (almost) as if it were a proper computer. Personnel on these forums have come up a working Debian kernel and root filesystem that is nearly plug-and-play , and requires only a few hardware-specific tweaks to unlock the full potential of these WD, and other similar appliances.


================================================================================
3. Software / Equipment Requirements
================================================================================


The biggest requirement is a UART console to the NAS. This can be accessed by an unpopulated header on the mainboard after removing the case. Connecting to the UART serial console on the EX4100 can be done with an RPi4, as I do in these instructions, but can also be done with a USB to UART adapter.
I've tested on an amd64 box with Adafruit's inexpensive USB-UART cable, and this works for kwboot and everything else. In my testing with the USB adapter, bubt/kwboot was a bit slower/noisier using this as my serial connection than connecting Dupont cables directly to the RPi4's expansion header. I may have also seen some issues due to USB serial buffer not flushing properly, but these were rare.
These instructions written for connecting RPi GPIO directly to the mainboard by the Dupont cables.

Note: There is some discussion/recommendation on UART adapters here:
(USB to UART adapter such as one with CP2102 chip)
Wiki thread: https://forum.doozan.com/read.php?8,13263

The following should be prepared ahead of time:
  • RPi4 (I had aarch64 raspbian installed with u-boot-tools )
  • Several Dupont cables and pins (Plug->Jack, Jack->Jack, and Plug->Plug). These can be bought for cheap on amazon for example, and are handy for RPi projects.
  • A decent soldering iron with fine tip, to solder pins onto the EX4100's unpopulated UART header. Mine was set at 450C before the factory solder would give. Alternately to soldering pins, alligator clips/electrical tape may be used as with hmartin's method (see links Ref 1.5), though soldering the pins provides a more permanent and reliable connection.
  • kwboot binary for your platform (I think this comes with Raspbian's u-boot-tools, but one is also linked in Refs)
  • Backups of your NAND partitions
  • A means to save a log of your session, in case you need "tech support"
  • A USB 2.0 flash drive to use as the Rootfs (and for optional u-boot update)


================================================================================
4. Tips for saving a Session Log
================================================================================


In case you need to ask questions on forums, having a session log is often helpful.
Here are some tips for keeping one:
GNU screen combined with ansifilter for "post-processing". Example: 
sudo apt-get install screen ansifilter -y
screen -S backupsession -T ansi -L -Logfile backup_mtd_ssh_session.log /dev/ttyS0 115200
then to remove escape characters and make a regular (and smaller-sized) textfile, use ansifilter: 
ansifilter backup_mtd_ssh_session.log > backup_mtd_ssh_session.txt
To detach screen terminal: Ctrl-A , D
To reattach, in shell prompt: screen -x
To kill, can use 'killall -9 screen'

Minicom can also be configured to save session output, example: 
minicom --wrap --term ansi --capturefile=session_kwboot_stock_uboot_backup.txt --capturefile-buffer-mode=L --device /dev/ttyS0 115200
PuTTY can be configured for logging similarly, (instructions not included), and the simple "Select-All"/"Copy-Paste" method can work fine as well.
Note: when using kwboot, ensure no other serial connections are opened (ie. with screen/minicom) to the NAS UART port - or else kwboot will not kwboot the box.


================================================================================
5. Backing up data on the NAS
================================================================================


To go ahead with this procedure, you should backup all the data on the NAS HDDs first.
Making the "modifications" described here carries some risk, and therefore you could potentially lose access to the existing data you may have stored on the stock WD RAID setup. Ensure all this data is backed up somewhere!
Remove all the drives from the NAS. I labelled mine Right-to-Left so that I'd know which drives went where, once it was time to set up the raid again, or in case I wanted to boot back into stock firmware.
My basic labelling: https://imgur.com/a/DGxTdhb - I removed the drives and stashed them away before continuing.

Make backups of the flash partitions:

Plug in a USB to the NAS and ssh in. In my case the USB becomes /dev/sda1, and was auto-mounted to /mnt/USB/USB1_a1/ on the EX4100 NAS. Note: at this time my NAS has all drives removed, so they are not shown in the output of 'df' 
root@WDMyCloudEX4100 ~ # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                53.4M     18.3M     32.3M  36% /
devtmpfs               1017.6M     32.0K   1017.6M   0% /dev
mdev                   1017.6M     32.0K   1017.6M   0% /dev
ubi0:config              12.1M    260.0K     11.2M   2% /usr/local/config
/dev/loop0              142.9M    142.9M         0 100% /usr/local/modules
tmpfs                     1.0M         0      1.0M   0% /mnt
tmpfs                    40.0M      1.8M     38.2M   5% /var/log
tmpfs                   100.0M      2.5M     97.5M   2% /tmp
/dev/sda1                28.9G         0     28.9G   0% /mnt/USB/USB1_a1

For logging and posterity, you should list the mtd layout, and a file listing of the backups.
A log of the session should be created, either manually by selecting and copy paste, or using logging options on your terminal emulator. Having a session log can facilitate recovery, reconfiguration, or asking for help, if needed. 
root@WDMyCloudEX4100 ~ # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00500000 00020000 "U-Boot"
mtd1: 00500000 00020000 "uImage"
mtd2: 00500000 00020000 "uRamdisk"
mtd3: 1b900000 00020000 "image.cfs"
mtd4: 00f00000 00020000 "rescue fw"
mtd5: 01400000 00020000 "config"
mtd6: 00a00000 00020000 "reserve1"
mtd7: 00a00000 00020000 "reserve2"
root@WDMyCloudEX4100 ~ # ls /dev/mtd*
mtd0       mtd1       mtd2       mtd3       mtd4       mtd5       mtd6ro     mtdblock0  mtdblock2  mtdblock4  mtdblock6
mtd0ro     mtd1ro     mtd2ro     mtd3ro     mtd4ro     mtd5ro     mtd7ro     mtdblock1  mtdblock3  mtdblock5  mtdblock7

Make a new dir on the mounted USB, and start backing up the NAND partitions. Note bad blocks on the mtd, especially in mtd0, where u-boot will reside.
Bad blocks here could potentially prevent successful re-burning of u-boot to the NAND partition within this address space. Below, mine shows bad blocks on mtd3 (used for resident WD firmware storage on this NAS), but this won't affect boot process. 
root@WDMyCloudEX4100 USB1_a1 # mkdir /mnt/USB/USB1_a1/mtd_backups
root@WDMyCloudEX4100 USB1_a1 # cd /mnt/USB/USB1_a1/mtd_backups
root@WDMyCloudEX4100 mtd_backups # nanddump --noecc --omitoob -f mtd0_noecc_nooob.bak /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00500000...
root@WDMyCloudEX4100 mtd_backups # nanddump --noecc --omitoob -f mtd1_noecc_nooob.bak /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00500000...
root@WDMyCloudEX4100 mtd_backups # nanddump --noecc --omitoob -f mtd2_noecc_nooob.bak /dev/mtd2
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00500000...
root@WDMyCloudEX4100 mtd_backups # nanddump --noecc --omitoob -f mtd3_noecc_nooob.bak /dev/mtd3
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x1b900000...
root@WDMyCloudEX4100 mtd_backups # nanddump --noecc --omitoob -f mtd4_noecc_nooob.bak /dev/mtd4
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00f00000...
root@WDMyCloudEX4100 mtd_backups # nanddump --noecc --omitoob -f mtd5_noecc_nooob.bak /dev/mtd5
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x01400000...
root@WDMyCloudEX4100 mtd_backups # nanddump --oob -f mtd0_ecc_oob.bak /dev/mtd0
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00500000...
root@WDMyCloudEX4100 mtd_backups # nanddump --oob -f mtd1_ecc_oob.bak /dev/mtd1
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
root@WDMyCloudEX4100 mtd_backups # nanddump --oob -f mtd2_ecc_oob.bak /dev/mtd2
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00500000...
root@WDMyCloudEX4100 mtd_backups # nanddump --oob -f mtd3_ecc_oob.bak /dev/mtd3
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 5
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x1b900000...
root@WDMyCloudEX4100 mtd_backups # nanddump --oob -f mtd4_ecc_oob.bak /dev/mtd4   
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00f00000...
root@WDMyCloudEX4100 mtd_backups # nanddump --oob -f mtd5_ecc_oob.bak /dev/mtd5   
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x01400000...

Save a session log (select > copy > paste if you must) of the above for posterity, store it with your backup files. 
root@WDMyCloudEX4100 mtd_backups # cat > mtd_backup_sesion_log.txt

Contents of mtd backups should look like so: 
root@WDMyCloudEX4100 mtd_backups # du -h .
997M    .
root@WDMyCloudEX4100 mtd_backups # ls -alh
drwxrwxrwx    2 admin    share      16.0K Oct 19 13:35 .
drwxrwxrwx    4 admin    share      16.0K Oct 19 13:25 ..
-rwxrwxrwx    1 admin    share       5.2M Oct 19 13:30 mtd0_ecc_oob.bak    
-rwxrwxrwx    1 admin    share       5.0M Oct 19 13:26 mtd0_noecc_nooob.bak
-rwxrwxrwx    1 admin    share       5.2M Oct 19 13:30 mtd1_ecc_oob.bak    
-rwxrwxrwx    1 admin    share       5.0M Oct 19 13:26 mtd1_noecc_nooob.bak
-rwxrwxrwx    1 admin    share       5.2M Oct 19 13:30 mtd2_ecc_oob.bak    
-rwxrwxrwx    1 admin    share       5.0M Oct 19 13:26 mtd2_noecc_nooob.bak
-rwxrwxrwx    1 admin    share     454.1M Oct 19 13:32 mtd3_ecc_oob.bak    
-rwxrwxrwx    1 admin    share     440.4M Oct 19 13:28 mtd3_noecc_nooob.bak
-rwxrwxrwx    1 admin    share      15.5M Oct 19 13:35 mtd4_ecc_oob.bak    
-rwxrwxrwx    1 admin    share      15.0M Oct 19 13:28 mtd4_noecc_nooob.bak
-rwxrwxrwx    1 admin    share      20.6M Oct 19 13:35 mtd5_ecc_oob.bak    
-rwxrwxrwx    1 admin    share      20.0M Oct 19 13:29 mtd5_noecc_nooob.bak
-rwxr-xr-x 	  1 admin    share        31K Oct 19 13:39 mtd_backup_sesion_log.txt

root@WDMyCloudEX4100 mtd_backups # ls -al
total 1020028
drwxr-xr-x    2 admin    share      4096 Oct 19 13:36 .
drwxr-xr-x    4 admin    share      4096 Oct 19 18:24 ..
-rwxr-xr-x    1 admin    share   5406720 Oct 19 13:30 mtd0_ecc_oob.bak
-rwxr-xr-x    1 admin    share   5242880 Oct 19 13:26 mtd0_noecc_nooob.bak
-rwxr-xr-x    1 admin    share   5406720 Oct 19 13:30 mtd1_ecc_oob.bak
-rwxr-xr-x    1 admin    share   5242880 Oct 19 13:26 mtd1_noecc_nooob.bak
-rwxr-xr-x    1 admin    share   5406720 Oct 19 13:30 mtd2_ecc_oob.bak
-rwxr-xr-x    1 admin    share   5242880 Oct 19 13:26 mtd2_noecc_nooob.bak
-rwxr-xr-x    1 admin    share 476196864 Oct 19 13:32 mtd3_ecc_oob.bak
-rwxr-xr-x    1 admin    share 461766656 Oct 19 13:28 mtd3_noecc_nooob.bak
-rwxr-xr-x    1 admin    share  16220160 Oct 19 13:35 mtd4_ecc_oob.bak
-rwxr-xr-x    1 admin    share  15728640 Oct 19 13:28 mtd4_noecc_nooob.bak
-rwxr-xr-x    1 admin    share  21626880 Oct 19 13:35 mtd5_ecc_oob.bak
-rwxr-xr-x    1 admin    share  20971520 Oct 19 13:29 mtd5_noecc_nooob.bak
-rwxr-xr-x    1 admin    share     30861 Oct 19 13:39 mtd_backup_sesion_log.txt
Save the backups, session log, and also the file listing like shown above to some trusted storage
Do not save them/excpect to keep them on the ex4100 NAS hard drives!!!


================================================================================
6. Disassembly of the NAS for UART connection
================================================================================

Note: IMHO, the soldering is the "most dangerous" part. There can be many methods to save or "unbrick" these boxes if something goes wrong when working with bootloader or flash partitions, but physically damaging the board would make for a terrible time! Though possibly less reliable, check out hmartin's solderless method where he uses alligator clips (link in Refs).

My photos below for reference:

================================================================================
7. Testing serial console, u-boot prompt, and kwboot
================================================================================

--------------------------------------------------------------------------------
7.1 Testing serial console:
--------------------------------------------------------------------------------
Once UART wires are connected to the RPi and NAS as in Step 8 photo above, you can ssh to he RPi and test that the UART communication is working with a utility such as screen,minicom,or picocom, on the RPi4. RPi's serial port should be called /dev/ttyS0.
Note: If /dev/ttyS0 doesn't exist on the RPi, disable the RPi4 local tty so we can use it for UART, and enable serial console hardware;
Bring up raspi-config, (sudo raspi-config)
Go to 'Interface Options' > 'Serial Port' >
Choose 'No' for 'login shell accessible over serial' > ()
Choose 'Yes' to enable serial port hardware >
Choose 'OK' to acknowledge the informative message >
Tab key over to 'Finish' at the main menu, and Reboot if prompted to do so.
ssh to the RPi as before, and /dev/ttyS0 should now be available.

Examples:

Picocom: 
picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0

For GNU screen: 
screen /dev/ttyS0 115200
or, with screen's session logging: 
screen -S serialtest -T ansi -L -Logfile serialtest.log /dev/ttyS0 115200

For minicom: 
minicom -D /dev/ttyS0 115200
or, with minicom's session logging: 
minicom --wrap --term ansi --capturefile=serialtest.txt --capturefile-buffer-mode=L --device /dev/ttyS0 115200

With either method above, you should have a functional console prompt to the NAS, either just as you would with ssh(for older MyCloudOS) or a login prompt(for MyCloudOS 5) - though many status and error lines are printed to this console. Make sure NAS has power plugged in.

Example: On MyCloud OS5, when viewing serial console after booting to stock firmware: 
read /var/log/alert_send.xml not exist

starting pid 4565, tty '/dev/ttyS0': '/bin/login'
Password:

--------------------------------------------------------------------------------
7.2 Save stock u-boot environment variables and mtd information:
--------------------------------------------------------------------------------

To check the u-boot status messages and poke around in the environment, reboot the NAS, while watching the serial console. Example output below: 

BootROM - 1.73
Booting from NAND flash

mvBoardIdGet: TWSI Read for Marvell Board ID failed (57)
        Using default board ID



General initialization - Version: 1.0.0
Detected Device ID 6828
High speed PHY - Version: 2.0

Initialize DB-88F6820-BP board topology
board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  06   |  SATA0      |
 |   1    |  00   |  SGMII1     |
 |   2    |  06   |  SATA1      |
 |   3    |  06   |  SATA3      |
 |   4    |  05   |  USB3 HOST0 |
 |   5    |  06   |  SATA2      |
 --------------------------------
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.26.0
mvSysEnvGetTopologyUpdateInfo: TWSI Read failed
DDR3 1 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
BootROM: Image checksum verification PASSED

 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_
        | | | |___|  _ \ / _ \ / _ \| __|
        | |_| |___| |_) | (_) | (_) | |_
         \___/    |____/ \___/ \___/ \__|
 ** LOADER **


U-Boot 2013.01_v1.06 (Jan 08 2015 - 10:04:46) Marvell version: 2014_T3.0p6

mvBoardSatRRead: Error: Read from S@R failed
mvBoardSatRRead: Error: Read from S@R failed
mvBoardSatRRead: Error: Read from S@R failed
Board: DB-88F6820-BP
SoC:   MV88F6828 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1600 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
       DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  2 GiB

Map:   Code:                    0x7fece000:0x7ff95d44
       BSS:                     0x7ffef254
       Stack:                   0x7f9cdf20
       Heap:                    0x7f9ce000:0x7fece000
raise: Signal # 8 caught
raise: Signal # 8 caught
       U-Boot Environment:      0x00000000:0x00080000 (NAND)

NAND:  ID: dcad ,512 MiB
MMC:   mv_sdh: 0
USB2.0 0: Host Mode
USB3.0 0: Host Mode
USB3.0 1: Host Mode
Board configuration detected:
Creating 1 MTD partitions on "nand0":
0x00001f500000-0x00001ff00000 : "mtd=7"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=7"
UBI: MTD device size:            10 MiB
UBI: number of good PEBs:        80
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             32
UBI: total number of reserved PEBs: 48
UBI: number of PEBs reserved for bad PEB handling: 2
UBI: max/mean erase counter: 4/1
UBIFS: mounted UBI device 0, volume 0, name "reserve2"
UBIFS: mounted read-only
UBIFS: file system size:   4063232 bytes (3968 KiB, 3 MiB, 32 LEBs)
UBIFS: journal size:       1015809 bytes (992 KiB, 0 MiB, 6 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root:  200807 bytes (196 KiB)
Loading file '/mac_addr' to addr 0x02000000 with size 36 (0x00000024)...
Done
lan mac_addr :  00 90 a9 e7 b6 2c
Set lan 0 WakeOnLan ok
Set lan 1 WakeOnLan ok
MicroP Enable HD
Enable HD1
Enable HD2
Enable HD3
Enable HD4
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x00     |
| egiga1 |   SGMII   |     0x01     |
egiga0 [PRIME], egiga1
Hit any key to stop autoboot:  0
Note: The power-button may need to be pushed (normally accessed via front panel, physical btn is on mainboard) to have the secondary microprocessor (the "uP" that controls fan, LEDs, LCD display, etc) continue the boot sequence. If the fan is plugged into the mainboard, the fan will be running once the uP sends this command. If the fan is not running but other lights are on, uP is waiting for you to push the power button (uboot prompt will be stuck at these 2lines:) 
Set lan 0 WakeOnLan ok
Set lan 1 WakeOnLan ok
after pushing power button, you will see the following, and fan will spin up: 
Set lan 0 WakeOnLan ok
Set lan 1 WakeOnLan ok
MicroP Enable HD
Enable HD1
Enable HD2
Enable HD3
Enable HD4
Repeatedly press '1' key to interrupt and get uboot prompt: 
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x00     |
| egiga1 |   SGMII   |     0x01     |
egiga0 [PRIME], egiga1
Hit any key to stop autoboot:  0
Marvell>>

Type "mtdparts" to display the NAND address offsets, and then "printenv" into the u-boot prompt. Save both information - ie. via session log - for posterity. 

Marvell>> mtdparts

device nand0 <armada-nand>, # parts = 8
 #: name                size            offset          mask_flags
 0: u-boot              0x000000500000          0x000000000000          1
 1: kernel              0x000000500000          0x000000500000          0
 2: uRamdisk            0x000000500000          0x000000a00000          0
 3: image.cfs           0x00001b900000          0x000000f00000          0
 4: rescue_fw           0x000000f00000          0x00001c800000          0
 5: config              0x000001400000          0x00001d700000          0
 6: reserve1            0x000000a00000          0x00001eb00000          0
 7: reserve2            0x000000a00000          0x00001f500000          0

active partition: nand0,0 - (u-boot) 0x000000500000 @ 0x000000000000

defaults:
mtdids  : none
mtdparts: none
Marvell>> printenv
CASset=max
MALLOC_len=5
MPmode=SMP
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
bootargs=root=/dev/ram console=ttyS0,115200
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params 
clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=nand read.e 0xa00000 0x500000 0x500000;nand read.e 0xf00000 0xa00000 0x500000;bootm 0xa00000 0xf00000
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;       
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000;
bootdelay=1
cacheShare=no
console=console=ttyS0,115200
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=00:50:43:95:33:36
eth1mtu=1500
eth2addr=00:50:43:95:26:36
eth2mtu=1500
eth3addr=00:50:43:33:26:95
eth3mtu=1500
ethact=egiga0
ethaddr=00:50:43:26:33:36
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
filesize=24
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=2.66.66.203
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtddevname=u-boot
mtddevnum=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:5m(u-boot)ro,5m@5m(kernel),5m@10m(uRamdisk),441m@15m(image.cfs),15m@456m(rescue_fw),20m@471m(config),10m@491m(reserve1),10m@501m(reserve2)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:36:26:95
nandEcc=nfcConfig=4bitecc
netbsd_en=no
netmask=255.255.255.0
netretry=no
partition=nand0,0
pcieTune=no
pexMode=RC
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=2.66.66.32
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;     
stderr=serial
stdin=serial
stdout=serial
usb0Mode=host
usbActive=0
usbType=3
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81

Environment size: 3202/524284 bytes
Marvell>>


--------------------------------------------------------------------------------
7.3 Test kwboot into bodhi's ex4100 tld-6 u-boot image:
--------------------------------------------------------------------------------

The stock U-Boot image as burned onto the EX2100/EX4100 by WD doesn't allow for the u-boot environment to be saved (ie., you can make changes to environment variables, but you cannot "saveenv" to have them persist). This poses issues since we intend to change the default boot parameters from booting the stock firmware from NAND, to booting a Debian rootfs that will reside on a USB drive or elsewhere.
Before making any changes to the U-Boot (this resides on the first NAND flash partition), we'll load a U-Boot by serial from the RPi4 to the NAS, which gets saved in RAM, and run only once. This u-boot is bodhi's tld-6 modified binary (link in Refs) which allows saving of environment variables (saveenv was enabled by bodhi in U-Boot configuration when WD GPL sources were compiled), and also ensures that all USB ports are powered when U-Boot is initializing.

Download bodhi's tld-6 u-boot binary image (Link: Ref 1.4), save it to the RPi,
Download the kwboot binary (Link: Ref 1.2), save to the same dir as the u-boot image.

Note: I think that having u-boot-tools installed on the RPi (u-boot-tools) in Raspbian, provides a "modern" kwboot which should work. For purposes of these instructions, a very up-to-date kwboot binary for Raspbian Linux aarch64 (RPi4) is included, check link in Ref 1.2.
Note: When running kwboot, make sure all serial sessions (ie. minicom or screen to /dev/ttyS0) are killed, as kwboot will need the ttyS0 to do the handshake and send the uboot!


Disconnect power cable from EX4100, run kwboot as follows from the RPi:
The '-t' flag for kwboot is required to be able to interact with the session. To exit kwboot serial session, use "Ctrl+|"->"x"
Using flags '-s 0 -q 1' is unnecessary for this board with the modern kwboot, and may cause more issues. 
eep@rpi4:~/ex4100project/kwboot $ ./kwboot_static_2024.04-rc3 -t -B 115200 /dev/ttyS0 -b uboot-ex4100-bodhi-tld-6-nand-uart.bin -s 0 -q 1
kwboot version 2024.04-rc3-00001-g0861eab8ec-dirty
Detected kwbimage v1 with UART boot signature     
Sending boot message. Please reboot the target...\
And insert the power cable. When successful, output appears as below: 
eep@rpi4:~/ex4100project/kwboot $ ./kwboot_static_2024.04-rc3 -t -B 115200 /dev/ttyS0 -b uboot-ex4100-bodhi-tld-6-nand-uart.bin -s 0 -q 1
kwboot version 2024.04-rc3-00001-g0861eab8ec-dirty
Detected kwbimage v1 with UART boot signature     
Sending boot message. Please reboot the target...|
Sending boot image header (71552 bytes)...
  0 % [......................................................................]
 12 % [......................................................................]
...
 87 % [..................................................................... ]
Done
Sending boot image data (884608 bytes)...
  0 % [......................................................................]
  1 % [......................................................................]
  2 % [......................................................................]
 ...
 98 % [......................................................................]
 99 % [...................................................                   ]
Done
Finishing transfer
[Type Ctrl-\ + c to quit]

 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_ 
        | | | |___|  _ \ / _ \ / _ \| __|
        | |_| |___| |_) | (_) | (_) | |_
         \___/    |____/ \___/ \___/ \__|
 ** LOADER **

...

Note bodhi's uboot that has saveenv capability shows a different version string: 
...
U-Boot 2013.01_v1.06 (Jun 30 2017 - 16:08:19) Marvell version: 2014_T3.0p6 - bodhi-tld-6
...
Also note, bodhi's tld-6 u-boot shows a more correct u-boot environment location: 
...
       U-Boot Environment:      0x00100000:0x00180000 Address: 0x00100000(NAND)
...

Note: if you see "noise"/garbage characters on the serial session, or if there are issues, try:
  • Ensure soldering is adequate
  • Ensure all 3 cables (Tx/Rx/Gnd) are connected securely
  • Ensure Tx from Pi goes to Rx on EX4100, and same "crossover" for the Rx cable.
  • As before, be sure serial port is not used on some other session on the Pi!

If all goes well (ie. you can do "mtdparts" and "printenv" within bodhi's kwbooted U-Boot, and get results from console), save the session log of the kwboot session for posterity, quit kwboot, and power off the NAS- next step will be to create a USB rootfs.


================================================================================
8. Setup bodhi's Debian rootfs for EX4100 on USB 2.0 flash drive
================================================================================

I used an 8GB USB 2.0 flash drive for my testing. I think USB 3.0 will work also, but I had a shortage of suitable drives available. TODO: Test/update
--------------------------------------------------------------------------------
8.1 Prepare a USB drive for rootfs
--------------------------------------------------------------------------------

Plug in USB2.0 flash drive to be used for rootfs. In this case my drive is a SanDisk 8GB at /dev/sda
In this case, my USB drive has some data and a partition, so first I wipe the drive 
eep@rpi4:~/ex4100project $ lsblk -o +FSTYPE,LABEL,VENDOR
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS    FSTYPE LABEL  VENDOR
sda           8:0    1  7.5G  0 disk                              SanDisk
└─sda1        8:1    1  7.5G  0 part                vfat   stuff
mmcblk0     179:0    0 29.8G  0 disk
├─mmcblk0p1 179:1    0  512M  0 part /boot/firmware vfat   bootfs
└─mmcblk0p2 179:2    0 29.3G  0 part /              ext4   rootfs

Use wipefs, specify partition and device to remove the previous label/partitions 
eep@rpi4:~/ex4100project $ sudo wipefs -a /dev/sda1 /dev/sda
/dev/sda1: 8 bytes were erased at offset 0x00000052 (vfat): 46 41 54 33 32 20 20 20
/dev/sda1: 1 byte was erased at offset 0x00000000 (vfat): eb
/dev/sda1: 2 bytes were erased at offset 0x000001fe (vfat): 55 aa
/dev/sda: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
/dev/sda: calling ioctl to re-read partition table: Success

Check again, should look as below: (no partitions, no label) 
eep@rpi4:~/ex4100project $ lsblk -o +FSTYPE,LABEL,VENDOR
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS    FSTYPE LABEL  VENDOR
sda           8:0    1  7.5G  0 disk                              SanDisk
mmcblk0     179:0    0 29.8G  0 disk
├─mmcblk0p1 179:1    0  512M  0 part /boot/firmware vfat   bootfs
└─mmcblk0p2 179:2    0 29.3G  0 part /              ext4   rootfs

Write new MBR partition table with !IMPORTANT! 'rootfs' as label
Note: GPT,ext4 does not work with the Yellowstone-tld-6 uboot , nor the stock WD uboot. 
eep@rpi4:~/ex4100project $ sudo parted -s /dev/sda \ mklabel msdos \ mkpart primary ext3 1MiB 100%
eep@rpi4:~/ex4100project $ sudo mkfs.ext3 -L rootfs /dev/sda1
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 1953792 4k blocks and 488640 inodes
Filesystem UUID: c2c112b9-81c2-40d2-a38d-a6b0592e8091
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

Notice now there is a properly labeled ext3 partition on the USB drive, ready to go for bodhi's rootfs: 
eep@rpi4:~/ex4100project $ lsblk -o +FSTYPE,LABEL,VENDOR
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS    FSTYPE LABEL  VENDOR
sda           8:0    1  7.5G  0 disk                              SanDisk
└─sda1        8:1    1  7.5G  0 part /media/sda1    ext3   rootfs
mmcblk0     179:0    0 29.8G  0 disk
├─mmcblk0p1 179:1    0  512M  0 part /boot/firmware vfat   bootfs
└─mmcblk0p2 179:2    0 29.3G  0 part /              ext4   rootfs

--------------------------------------------------------------------------------
8.2 Create the rootfs on the prepared USB drive
--------------------------------------------------------------------------------

Download bodhi's latest rootfs from the forum: https://forum.doozan.com/read.php?2,32146,32146#msg-32146 In this case latest from bodhi is 6.6.2. Be sure to verify Hashes for this archive as follows (from the post linked above): 
md5:
009d315ebc813868344ce9221bcc3c70
sha256:
50ceb6465c46399901ab52406e15fd6406d53ec9d682d066f9fe9a87f779077f
eep@rpi4:~/ex4100project $ wget https://bit.ly/3Tq9pTO -O Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2
Verify the hashes on ALL downloaded files, before extracting!!
If they don't match, download and verify again, or make a post on forum. 
eep@rpi4:~/ex4100project $ md5sum Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2 && sha256sum Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2
009d315ebc813868344ce9221bcc3c70  Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2
50ceb6465c46399901ab52406e15fd6406d53ec9d682d066f9fe9a87f779077f  Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2

Make a dir for the rootfs and mount the USB 
eep@rpi4:~/ex4100project $ sudo mkdir -p /media/sda1
eep@rpi4:~/ex4100project $ sudo mount /dev/sda1 /media/sda1/

Note: The next series of steps will involve creating/modifying files on the mounted rootfs. At this point we su to the root user. Using sudo to extract the files may cause some issues creating the rootfs, ie. with file ownership/permissions. To avoid chance for frustration, extract the files from the tarball to the mount point as root! (same for mkimage steps) 

eep@rpi4:~/ex4100project $ sudo su
root@rpi4:/home/eep/ex4100project # tar -jxf  Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2 -C /media/sda1/
root@rpi4:/home/eep/ex4100project # cd /media/sda1/boot/
root@rpi4:/media/sda1/boot # cp -a zImage-6.6.2-mvebu-tld-1 zImage.fdt
root@rpi4:/media/sda1/boot # sync
root@rpi4:/media/sda1/boot # sync
Run sync after extracting and copying the zImage, as a lot of files were transferred to the USB filesystem, they are not fully written to the disk until sync completes. To prevent issues in future, run sync again. It takes a while the first time, but exits immediately if there's nothing to sync.
Append the device tree definitions (included in the archive) to the provided image, sync again. 
root@rpi4:/media/sda1/boot # cat dts/armada-388-wd-ex4100.dtb >> zImage.fdt
root@rpi4:/media/sda1/boot # cp -a uImage uImage.orig
root@rpi4:/media/sda1/boot # sync
Generate a uImage and uInitrd for ARM using mkimage (u-boot-tools package on Debian/Raspbian) 
root@rpi4:/media/sda1/boot # mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-6.6.2-mvebu-tld-1 -d zImage.fdt uImage
Image Name:   Linux-6.6.2-mvebu-tld-1
Created:      Sat Oct 19 18:46:44 2024
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    5197128 Bytes = 5075.32 KiB = 4.96 MiB
Load Address: 00008000
Entry Point:  00008000
root@rpi4:/media/sda1/boot # sync
root@rpi4:/media/sda1/boot # mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs 6.6.2-mvebu-tld-1 -d initrd.img-6.6.2-mvebu-tld-1 uInitrd
Image Name:   initramfs
Created:      Sat Oct 19 18:47:09 2024
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:    5257109 Bytes = 5133.90 KiB = 5.01 MiB
Load Address: 00000000
Entry Point:  00000000
root@rpi4:/media/sda1/boot # sync
Update the /etc/fw_env.config for bodhi's uboot for the ex4100 (Yellowstone_2014T30p6_bodhi-tld-6-nand-uart)
The default values for offset and mtd partition# within the rootfs is not correct for the ex4100: 
root@rpi4:/media/sda1/boot # cat ../etc/fw_env.config 
# MTD device name       Device offset   Env. size       Flash sector size       Number of sectors

/dev/mtd1               0x0000          0x80000         0x20000                 4
Update them to match the expected environment partition and address offset as flashed/reported by u-boot: 
root@rpi4:/media/sda1/boot # sed -i 's/0x0000/0x100000/g' /media/sda1/etc/fw_env.config 
root@rpi4:/media/sda1/boot # sed -i 's/mtd1/mtd0/g' /media/sda1/etc/fw_env.config
File should look like this (for the Yellowstone-tld-6-uboot by as built by bodhi in 2017): 
root@rpi4:/media/sda1/boot # cat ../etc/fw_env.config
# MTD device name       Device offset   Env. size       Flash sector size       Number of sectors

/dev/mtd0               0x100000                0x80000         0x20000                 4
Make a new dir inside rootfs boot dir to stash both the backed-up WD uboot, as well as bodhi's 'unlocked' u-boot in 'kwb'(NAND) and .bin(UART) versions:


Original post for UART-tld6: https://forum.doozan.com/read.php?2,34103,35230#msg-35230

Note: Original post for mtd0-tld6: https://forum.doozan.com/read.php?2,34103,35255#msg-35255
hashes of tarball: 
uboot.2014T30p6-tld-6.wd-mycloud-ex4100.bodhi.tar
md5:
c9dc826d545317fa6367902d2511630a
sha256:
b85afb164eb767fb63997ac3d5db877079bb752e1cc286fdbe1063691cc1dc39 

root@rpi4:/media/sda1/boot/uboot_images # sha256sum u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6-nand-uart.bin 
f580f7b0a0ef88d9b2a263195012957c82efa021ff742861be034b9934a7f1f1  u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6-nand-uart.bin

root@rpi4:/media/sda1/boot/uboot_images # sha256sum u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb 
08f17d763effd6f24febf8859ef8bf163836481e1b56483dfce1853e605a11db  u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb
Check the hashes! 
root@rpi4:/media/sda1/boot/uboot_images # wget https://bitly.com/2tB1PKy -O uboot.2014T30p6-tld-6.wd-mycloud-ex4100.bodhi.tar
echo "b85afb164eb767fb63997ac3d5db877079bb752e1cc286fdbe1063691cc1dc39  uboot.2014T30p6-tld-6.wd-mycloud-ex4100.bodhi.tar" | sha256sum -c
root@rpi4:/media/sda1/boot/uboot_images # tar xvf uboot.2014T30p6-tld-6.wd-mycloud-ex4100.bodhi.tar

The file 'u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb' is the one that will be burned to flash from inside Debian later.
kwboot utility can boot from either the .kwb or the .bin or even the mtd0 dump.

Drop from root user to regular user because we're done working on the rootfs.
Copy all three uboots here so they can be flashed from inside Debian: 
root@rpi4:/media/sda1/boot # mkdir uboot_images
root@rpi4:/media/sda1/boot # exit
exit
eep@rpi4:~/ex4100project $ ls kwboot/
kwboot_static_2024.04-rc3  uboot-ex4100-bodhi-tld-6-nand-uart.bin  uboot-ex4100-factory-nand.bin
eep@rpi4:~/ex4100project $ sudo cp kwboot/*.bin /media/sda1/boot/uboot_images/
eep@rpi4:~/ex4100project $ sudo cp kwboot/*.kwb /media/sda1/boot/uboot_images/
eep@rpi4:~/ex4100project $ sync
Unmount the flash drive, rootfs setup finished. 

eep@rpi4:~/ex4100project $ sudo umount /dev/sda1

eep@rpi4:~/ex4100project $ lsblk -o +FSTYPE,LABEL,VENDOR
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS    FSTYPE LABEL  VENDOR
sda           8:0    1  7.5G  0 disk                              SanDisk
└─sda1        8:1    1  7.5G  0 part                ext3   rootfs
mmcblk0     179:0    0 29.8G  0 disk
├─mmcblk0p1 179:1    0  512M  0 part /boot/firmware vfat   bootfs
└─mmcblk0p2 179:2    0 29.3G  0 part /              ext4   rootfs


================================================================================
9. Test booting into USB rootfs from kwbooted u-boot
================================================================================


At this point we'll kwboot the EX4100 into bodhi's tld-6 u-boot, interrupt to get console, manually update the u-boot envs to set up boot into USB rootfs, and test to make sure that works.

To do this, insert the USB with the rootfs into the one of the USB ports on the NAS (I've tested all 3, the front, and both rear ports work just fine, when using with bodhi's tld-6 u-boot), and then fire up kwboot as described in 7.3., ie:
With session logging enabled: 
screen -S uboot_update_full_session_ex4100 -T ansi -L -Logfile uboot_update_full_session_ex4100.log
Run kwboot inside screen: 
 ./kwboot_static_2024.04-rc3 -t -B 115200 /dev/ttyS0 -b uboot-ex4100-bodhi-tld-6-nand-uart.bin -s 0 -q 1
Output should be as before, kwboot will upload by serial the u-boot image and boot from it.



================================================================================
10. Set up EX4100 to boot from USB into Debian rootfs
================================================================================

When bodhi's u-boot starts loading (noted the version string!), interrupt the prompt as before, print the 'mtdparts' and 'printenv' as before.
Into the "Marvell>>" U-Boot prompt, update the boot settings within u-boot environment by pasting line-by-line the following, to set up for the box USB boot: 
setenv bootdev usb

setenv device '0:1'

setenv load_initrd_addr 0x2900000

setenv load_image_addr 0x02000000

setenv load_initrd 'echo loading uInitrd ...; ext2load $bootdev $device $load_initrd_addr /boot/uInitrd'

setenv load_image 'echo loading Image ...; ext2load $bootdev $device $load_image_addr /boot/uImage'

setenv usb_set_bootargs 'setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootdelay=10 earlyprintk=serial $mtdparts'

setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; usb start; run load_image; run load_initrd ; run usb_set_bootargs; bootm $load_image_addr $load_initrd_addr'

setenv bootcmd_usb 'run usb_set_bootargs; run usb_bootcmd; reset'

saveenv

printenv

mtdparts

run bootcmd_usb

On success, you should see the box boot into Debian! Login as root:root, and check that fw_printenv utility is setup properly to read u-boot environment: 
Debian GNU/Linux 12 debian ttyS0

debian login: root
Password: 
Linux debian 6.6.2-mvebu-tld-1 #1 SMP PREEMPT Mon Nov 20 18:44:27 PST 2023 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Dec 12 15:13:34 PST 2023 from fe80::4f8:63a5:4900:ad47%eth0 on pts/0
debian
WD My Cloud EX4100
Linux version 6.6.2-mvebu-tld-1 (root@tldDebian) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Mon Nov 20 18:44:27 PST 2023
Debian 12.4
Sat Nov 2 12:20:51 PDT 2024 up 2 minutes
root@debian:~# fw_printenv
CASset=max
MALLOC_len=5
MPmode=SMP

...

yuk_ethaddr=00:00:00:EE:51:81
root@debian:~#

Next, flash bodhi's u-boot image to NAND from inside Debian
Firstly, check for bad blocks within 1st MB of NAND (block 0-7) this will affect u-boot being properly written.
Do not proceed if there are bad blocks! 
dmesg | grep -i 'Bad eraseblock'
Should have no output

Next, check correct alignment of mtd0: 
root@debian:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00500000 00020000 "U-Boot"
...

Next, cd to uboot_images directory created on rootfs earlier, with bodhi's tld-6 uboot for NAND.
Verify the hashes!!! 

root@debian:~# cd /boot/uboot_images/
root@debian:/boot/uboot_images# sha256sum u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb
08f17d763effd6f24febf8859ef8bf163836481e1b56483dfce1853e605a11db  u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb

If the hashes are OK, the image can be written to flash. The flash must be erased before being written: 
root@debian:/boot/uboot_images# flash_erase /dev/mtd0 0 8
Erasing 128 Kibyte @ e0000 -- 100 % complete 
root@debian:/boot/uboot_images# nandwrite /dev/mtd0 u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000
root@debian:/boot/uboot_images#

Note: If there is any error during flashing or the output is different, stop and go to the forum for help.


Update the boot command hardcoded in this uboot: 
root@debian:/boot/uboot_images# fw_setenv bootcmd_custom 'run usb_bootcmd'

Now, everything should be configured to boot by default to the USB rootfs with the newly-flashed u-boot.
Shut down the NAS: 
root@debian:/boot/uboot_images# shutdown -h now
Exit kwboot and screen, and pull power cord from NAS. 
Ctrl + | , then 'c'
to quit kwboot.

Ctrl + A, then 'k', then confirm with 'y', to quit screen.

Setup another screen session to monitor bootup (which should boot to Debian by default now, without kwboot or entering u-boot envs) just to confirm that everything went fine: 
 
eep@rpi4:~/ex4100project/kwboot $ screen /dev/ttyS0 115200
and re-plug the power cable. It should boot to Debian without intervention!


================================================================================
11. Configure Debian for EX4100 (necessary and helpful tweaks)
================================================================================


Update Debian and Kernel
See instructions on MVEBU rootfs thread: https://forum.doozan.com/read.php?2,32146

Set up swap file
See instructions/notes on this post: https://forum.doozan.com/read.php?2,133753

Set up persistent MAC address
Check notes section of MVEBU rootfs thread: https://forum.doozan.com/read.php?2,32146

TODO:
  • set up SATA raid using mdmadm
  • control fans, LEDs, etc using mcm-daemon or WD scripts

For now: search the forum on how to do this, instructions are out there, but,
as always, follow at your own peril.

================================================================================
12. Restore stock WD firmware / U-Boot
================================================================================

Several methods work to update the firmware on this box (but many don't!).

From personal experience, the most reliable has been via TFTP:
TODO: Detailed instructions

The second most reliable method is via USB bubt:
TODO: Detailed instructions

The third most reliable method is by loading from USB via fatload, then writing via nand erase / nand write.
TODO: Detailed instructions

Using the flash_erase/nandwrite from inside Debian works also (for raw / mtd u-boot)


The important thing to keep in mind: DO NOT TRY TO WRITE A UART IMAGE TO THE FLASH with nandwrite!
  • tftpboot will write a NAND/UART image or even raw mtd dump, patching as needed
  • bubt can figure out that an image is built as a UART boot image, and patch it to a NAND image automatically;
  • nandwrite (from inside Debian) will destroy/corrupt the boot flash if it isn't used with a NAND image!

To restore, essentially, use one of the update methods listed in 11.
To restore from mtd0 backup, use tftpboot.
  1. Set up tftp server, and place the mtd0 raw file that was backed up at the beginning.
  2. Interrupt uboot console.
  3. Set ipaddr, serverip, and netmask.
  4. Start tftpboot from uboot.
You can also format a FAT32 drive, make a directory called "EX4100", and drop a file named "u-boot.bin" in that directory. Plug in the USB into the NAS, power on the NAS and hold the USB push-button for about 10 seconds. The NAS will attempt to flash u-boot from this file. The file can be your mtd0 backup (just rename to u-boot.bin).

See this post and attachments: https://forum.doozan.com/read.php?3,138181,138285#msg-138285

For some alternative means of restoring/updating uboot, and some "bonus info"
(detailed instructions may be written one day)



Edited 2 time(s). Last edit at 11/24/2024 10:39AM by eep.
Reply Quote
eep
Re: How-To: Debian and U-Boot on WD MyCloud EX4100
November 02, 2024 04:31PM
Changelog:

11-24-2024 - applied changes based on comments from bodhi https://forum.doozan.com/read.php?2,138350,138359#msg-138359



Edited 1 time(s). Last edit at 11/24/2024 10:39AM by eep.
Reply Quote
bodhi
Re: How-To: Debian and U-Boot on WD MyCloud EX4100
November 02, 2024 06:05PM
eep,

Kudos! there are quite lot to digest. I'll come back to this.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
bodhi
Re: How-To: Debian and U-Boot on WD MyCloud EX4100
November 03, 2024 03:24PM
eep,

I've made the first pass reading the instruction. The writing and details are fantastic! perhaps a bit too detailed, but it's good for Linux beginners. I have comments below. As I make a seconds pass I will post more comments if needed.

Quote

The biggest requirement is a UART console to the NAS. This can be accessed by an unpopulated header on the mainboard after removing the case. Connecting to the UART serial console on the EX4100 can be done with an RPi4, as I do in these instructions, but can also be done with a USB to UART adapter.

USB to UART adapter such as one with CP2102 chip:
Wiki thread: https://forum.doozan.com/read.php?8,13263

Quote

For GNU screen:
screen /dev/ttyS0 115200
or, with screen's session logging:
screen -S serialtest -T ansi -L -Logfile serialtest.log /dev/ttyS0 115200

For minicom:
minicom -D /dev/ttyS0 115200
or, with minicom's session logging:
minicom --wrap --term ansi --capturefile=serialtest.txt --capturefile-buffer-mode=L --device /dev/ttyS0 115200

With either method above, you should have a functional console prompt to the NAS, either just as you would with ssh(for older MyCloudOS) or a login prompt(for MyCloudOS 5) - though many status and error lines are printed to this console. Make sure NAS has power plugged in.

The above is probably too much (but I'm not against being wordy). A simple command to illustrate the parameters like this would suffice 
picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0

Quote

The '-s 0 -q 1' are some extra timing parameters that may not be necessary for this board with the modern kwboot, but I use them anyway for good measure.

Don't use these parameters (it could make it worse). The latest kwboot already taken care of the handshake in a robust way for this Armada 385 BootROM (OTOH, the -a parameter is quite valid when running with an Armada XP target).

Quote

Check the hashes!
root@rpi4:/media/sda1/boot/uboot_images # wget https://bitly.com/2tB1PKy -O uboot.2014T30p6-tld-6.wd-mycloud-ex4100.bodhi.tar
root@rpi4:/media/sda1/boot/uboot_images # sha256sum uboot.2014T30p6-tld-6.wd-mycloud-ex4100.bodhi.tar
b85afb164eb767fb63997ac3d5db877079bb752e1cc286fdbe1063691cc1dc39 uboot.2014T30p6-tld-6.wd-mycloud-ex4100.bodhi.tar

....
root@debian:~# cd /boot/uboot_images/
root@debian:/boot/uboot_images# sha256sum u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb
08f17d763effd6f24febf8859ef8bf163836481e1b56483dfce1853e605a11db u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb

Save the user sometime matching the hash manually by using sha256sum -c 
echo "b85afb164eb767fb63997ac3d5db877079bb752e1cc286fdbe1063691cc1dc39  uboot.2014T30p6-tld-6.wd-mycloud-ex4100.bodhi.tar" | sha256sum -c

Quote

If the hashes are OK, the image can be written to flash. The flash must be erased before being written:
root@debian:/boot/uboot_images# flash_erase /dev/mtd0 0 8
Erasing 128 Kibyte @ e0000 -- 100 % complete
root@debian:/boot/uboot_images# nandwrite /dev/mtd0 u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000

Add a note to tell the user if there is any error during flashing or the output is different, stop and goto the forum for help.

Quote

TODO:
Update Debian and kernel
Point to the rootfs and kernel release thread.

Quote

Set up swapfile
Persistent mac Address
Point to the Notes sections in rootfs and kernel releases. No need to rewrite the details

Quote

set up SATA raid using mdmadm
This is in the Wiki thread. But it's probably better to writing a new one in a separate thread and link it here. We don't have enough of this type of instruction. A separate thread would be good for people to get help.

Quote

================================================================================
12. Restore stock WD firmware / U-Boot
================================================================================

Several methods work to update the firmware on this box (but many don't!).

From personal experience, the most reliable has been via TFTP:
TODO: Detailed instructions

The second most reliable method is via USB bubt:
TODO: Detailed instructions

The third most reliable method is by loading from USB via fatload, then writing via nand erase / nand write.
TODO: Detailed instructions

Using the flash_erase/nandwrite from inside Debian works also.

I would prefer the method of using the backup files and flash them from inside Debian. But other methods are OK.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
bodhi
Re: How-To: Debian and U-Boot on WD MyCloud EX4100
November 05, 2024 06:16PM
Up in the 1st post of the MVEBU kernel and rootfs release thread

Quote

Installation Instruction for specific boxes (in chronological order):
....
....
WD MyCloud EX4100 Installation: see this thread (work-in-progress)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
Newer Topic Older Topic
Author:

Your Email:


Subject:
Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: