Last update: 02-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:
- References and Links
- Rationale
- Software / Equipment Required
- Tips for saving a Session Log
- Backing up data on the NAS
- Accessing on-board UART
- Testing with kwboot
- Setup Debian rootfs for EX4100 on USB 2.0 flash drive
- Burn customized U-Boot on EX4100 NAND flash
- Set up EX4100 to boot from USB into Debian rootfs
- Configure Debian for EX4100 (necessary and helpful tweaks)
- 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.
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 115200then to remove escape characters and make a regular (and smaller-sized) textfile, use ansifilter:
ansifilter backup_mtd_ssh_session.log > backup_mtd_ssh_session.txtTo 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 115200PuTTY 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.txtSave 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:
- RPi4 GPIO Pinout: https://imgur.com/a/Yj8jQ7M
- Step 0: Label,remove drives, put away to save from wear (ie. from rebooting) and etc. - https://imgur.com/a/DGxTdhb
- Step 1: Remove enclosure - https://imgur.com/a/h63FDzH
- Step 2: Remove Front Panel - https://imgur.com/a/dvP6Eci
- Step 3: Remove Rear Panel - https://imgur.com/a/dI5B7Nn
- Step 4: Free and remove the mainboard - https://imgur.com/a/jjeo0Ws
- Step 5: Soldering the pins to empty UART header. (I soldered already) - https://imgur.com/a/GZGFjCV
- Step 6: Feed wires through NAS vent holes - https://imgur.com/a/l9bVWTp
- Step 7: Connect UART to RPi4 headers - https://imgur.com/a/mcpkwQV
- Step 8: UART and EX4100 power is connected (no Eth conx to NAS, oops) - https://imgur.com/a/wDxXKW9
================================================================================
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:
For GNU screen:
screen /dev/ttyS0 115200or, with screen's session logging:
screen -S serialtest -T ansi -L -Logfile serialtest.log /dev/ttyS0 115200
For minicom:
minicom -D /dev/ttyS0 115200or, 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 okafter 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 HD4Repeatedly 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"
The '-b' flag specifies the local uboot image file to send
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.
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.bz2Verify 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 # syncRun 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 # syncGenerate 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 # syncUpdate 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 4Update 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.configFile 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 4Make 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.kwbCheck 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@rpi4:/media/sda1/boot/uboot_images # tar xvf uboot.2014T30p6-tld-6.wd-mycloud-ex4100.bodhi.tar u-boot-a38x-Yellowstone_2014T30p6_bodhi-tld-6.mtd0.kwb 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 root@rpi4:/media/sda1/boot/uboot_images #
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 $ syncFinally, unmount the flash drive, rootfs is ready to go.
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 rootfsGreat, the rootfs has been made! Instructions for updating kernel and other "tweaks" later.
================================================================================
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.logRun 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 1Output 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#Finally, 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 nowExit 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 115200and re-plug the power cable. It should boot to Debian without intervention!
================================================================================
11. Configure Debian for EX4100 (necessary and helpful tweaks)
================================================================================
TODO:
- Update Debian and kernel
- Set up swapfile
- Persistent mac Address
- 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.
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, and it will work, automagically.
- bubt can figure out that an image is built as a UART boot image, and 'translate' it to a NAND image automatically, on update;
- 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.
- Set up tftp server, and place the mtd0 raw file that was backed up at the beginning.
- Interrupt uboot console.
- Set ipaddr, serverip, and netmask.
- Start tftpboot from uboot.
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)