Unbrick my My Cloud Ex2 from blue blink after using self compiled kernel

Hi guys,

I spent nearly the complete week here, reading about successful/unsuccessful stories of people that were flashing their NAS to get rid of the crappy firmware and do with the hardware what is possible. I was buzzed by all the creativity, cleverness and engineering power (props for here and here to @Fox_exe, and @TCWORLD ) that went into turning the closed source box into something useful.

It took me some time to get sorted: Learning about my model and its names, learning where it was different from the other boxes, getting an overview of all the possibilities to approach opening the device and how to ‘unbrick’ it properly if something goes wrong.

I have made a lot of unsuccessful steps but step by step getting to a clean Debian 10 with OMV on the device. I was at 95% of my targeted solution when I realized that many modules cannot get loaded and e.g. systemd, chrony, md.monit, and some other services are not working. Also the system time was 1.1.1970 after each reboot.

From what I learned during this week was that I might have to cross compile my own kernel and so I did it: I had minor issues during cross compilation, when the linker complained that (If I recall correctly) the memory module was missing the AMBA object and so I removed AMBA support without understanding what it is for because I can always unbrick my device … (btw I would not remove AMBA again!).

Until the end I was not 100% sure what uBoot and uImage is but my cross compilation generated the uImage and sind I followed the cross compilation tutorial I just created the tar with the modules, and copied it, together with the uImage over to my NAS and dd-ed the uImage over the partition.

Now, after a reboot the blue light blinks repeatedly, the netword device does not come up (nmap doesnt find it any longer), the recovery mode with keeping the reset button pressed does not work any longer (I always saw from the red and amber HDD lights alone that telnet is open) and the USB booting never worked for me anyhow.

I thought I might have a few possibilities left open to unbrick my device:

  1. by somehow getting a network boot done using tftp but I do not know if this is possible
  2. by using UART → similiar situation. So I bought a UART to USB device from China. However, according to the delivery plans I can wait 30-50 days until it is delivered.
  3. Connect pins on the board to bring the box into a rescue mode or let it restore the linux ramdisk.

I have no experience with but I am willing to learn and bring back that device to the living.

Does anyone of you have a good idea what I shall and could do in my situation?

Any help appreciated. Thanks!

When you got UART adapter - use this command for boot from TFTP server:

dhcp; setenv serverip 192.168.1.10; tftp 0xa00000 uImage; tftp 0xf00000 uRamdisk; bootm 0xa00000 0xf00000
  • 192.168.1.10 - IP address of tftp server.

Some info and files for kernel compilation: https://fox-exe.ru/WDMyCloud/Other/Official_linux_kernel/ (Use my config as base! Tested/compiled on Debian Jessie and Buster)

Thank you, I will try that. Unfortunately it takes at least a month to get the UART adapter. Is there anything I could do in the meantime?

I have a raspberry Pi 3 and a board and some electronics. Can I assemble an UART device on my own?

Seems like the Raspberry 3B rev 1.2 (and probably the other models as well) are capable of reading TTL (UART) and they have both, 5V and 3.3V. Tx, Rx, and GND can safely be connected and I see the bootup information. It all ends in

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

So I’m on the right track.

Using minicom or picocom from my raspberry pi I often see weird data. Sometimes it starts normal and then turns into transmitting binary, sometimes its binary only, and sometimes picocom aborts with

FATAL: read zero bytes from port
term_exitfunc: reset failed for dev UNKNOWN: Input/output error

I have tried picocom

sudo picocom --baud 115200 --logfile $(date -Iseconds).log /dev/ttyS0

and I have tried minicom

sudo minicom --baud 115200 -D /dev/ttyS0 -C $(date -Iseconds).log

I seem not to be able to stop the boot. Neither <1><1>… nor connecting RX and TX on the device stopped the boot sequence.

I also seem to not be able to send any data: What I expect is that when sending any keystroke that it gets transmitted and I see the text appearing on the virtual console. Isn’t that correct? Whatever I type seems to have no effect.

https://docs.fedoraproject.org/en-US/Fedora/21/html/System_Administrators_Guide/sec-Using_screen_to_Connect_to_the_Serial_Console.html

right, screen is nice. i also foud cu (which is used in screen and such not worth testing).
Anyhow, I get the same behavior for screen as for minicom and picocom.
I feel picocom has the best results. Also minicom is discuraged on the u-boot
These are example results, maybe you guys can have an educated guess on what the problem might be:

�b��zr���9�s�:�#P23�1aA50 ::�(r��pqL��Q��=}]s�X�ԫP�yp��X�ԫ�:�9� Y�#�zbQ�y8r��� �bA�Қ����0�X�pP:;�9�'x+J����p0i:� �(3o��S�0CQ`�:�{���1�8
                                                                                                                                       ��� ���`W+10�=�aȈ�`W+1�0"
                     ���"2q2��CB�A�s��e�`b��g�8q�z`�r!�rxi00 K�'����c2�:pc��(jQ`�+#��=��
                                                                                        ��XK��20G�;
                                                                                                     ��Xp�9�0�s��q=
                                                                                                                   ���Yk���`r:3;:��:(33(�1�p#���ai�x2�ï�2:��R:�C�w����x�310������C��C``E
                                             �;010�C��û�:;�0���8����C

The terminal does not write anything new now. I have to kill the program.

X�b��zr��L��s�:�#P23�1aA50 ::�(r���pq��Q��=}]s�X�ԫP�yp��X�ԫ�:�9� Y�#�
FATAL: read zero bytes from port
term_exitfunc: reset failed for dev UNKNOWN: Input/output error
    s*pp�zr���9�s�:�#P23�1aA50 ::�(r���pq��Q��=}]s�X���P�yp��X�ԫ�:�9� Y�#�zb�Q��8r��� �bA�ҚS����0�X�O�pP:��9��'x+J▒���p0i:� ��(3���S��0CQ`�:�{����▒1�8
    �� ��▒@�`W+10�=�b       a�▒�▒`W+100"�
                                         ���"2q2��CBA�s�▒�e�`b��g�8q�z`�r!��xi00 K�'����c2�:pc��(jQ`�+#��=��;
                                                                                                             ��XK�2���20��;
                                                                                                                           ��Xp�9�0�s���q=
                                                                                                                                          ���Yk���9#h3��
    BootROM 1.08
    Booting from NAND flash
    High speed PHY - Version: 2.1.2 (COM-PHY-V20) 
    Update PEX Device ID 0x67100
    High speed PHY - Ended Successfully
    DDR3 Training Sequence - Ver 4.5.0 
    DDR3 Training Sequence - Ended Successfully 
    Status = MV_OK
    B vPSED
     ** LOADER **
    U-Boot 2011.12 (Dec 24 2013 - 20:21:45) Marvell version: v2011.12 2013_Q1.2 (ALPHA U-BOOT : 1.0)
    Board: RD-88F6710_ALpha_KingsCanyon
    SoC:   MV6710 A1
    CPU:   Marvell PJ4B v7 UP (Rev 1) LE
           CPU    @ 1200 [MHz]
           L2     @ 600 [MHz]
           TClock @ 200 [MHz]
           DDR    @ 600 [MHz]
           DDR 16Bit Width, FastPath Memory Access
    DRAM:  512 MiB
    Map:   Code:            0x1fef5000:0x1ff9faac
           BSS:             0x1ffef784
           Stack:           0x1f9f4ef8
           Heap:            0x1f9f5000:0x1fef5000
    NAND:  flash id : daad
    256 MiB
    MMC:   MRVL_MMC: 0
    Bad block table found at page 131008, version 0x01
    Bad block table found at page 130944, version 0x01
    nand_read_bbt: Bad block at 0x00000e7c0000
    PEX 0: Root Complex Interface, Detected Link X1, GEN 2.0
    PEX 0.1(1): Detected No Link.
    FPU not initialized
    USB 0: Host Mode
    USB 1: Host Mode
    Modules/Interfaces Detected:
           RGMII1 Phy
           PEX0 (Lane 0)
           PEX1 (Lane 1)
           SATA0 (Lane 2)
           SATA1 (Lane 3)
    Not Marvell PHY id1 ffff id2 ffff
    Enable HD1
    Warning: egiga1 MAC addresses don't match:
    Address in SROM is         00:50:43:02:00:00
    Address in environment is  00:50:43:02:02:00
    Hit any key to stop autoboot:  0 
    NAND read: device 0 offset 0x500000, size 0x500000
     5242880 bytes read: OK
    NAND read: device 0 offset 0xa00000, size 0x500000
     5242880 bytes read: OK
    ## Booting image at 00a00000 ...
    ## Booting kernel from Legacy Image at 00a00000 ...
       Image Name:   armada-370-wdmc-mirror-gen1
       Created:      2020-12-03  20:20:39 UTC
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    4305717 Bytes = 4.1 MiB
       Load Address: 00008000
       Entry Point:  00008000
    ## Loading init Ramdisk from Legacy Image at 00f00000 ...
       Image Name:   Ramdisk
       Created:      2017-02-04  18:43:13 UTC
       Image Type:   ARM Linux RAMDisk Image (lzma compressed)
       Data Size:    2679802 Bytes = 2.6 MiB
       Load Address: 00e00000
       Entry Point:  00e00000
       Loading Kernel Image ... OK
    OK
    Starting kernel ...
    DTB:0x0041F8E8 (0x00003A4D)
    C:0x000080C0-0x004233C0->0x00D77A00-0x01192D00
    DTB:0x0118F228 (0x00003AD6)
    Uncompressing Linux... done, booting the kernel.
    Linux version 5.10.0-rc6+ (david@debian) (arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #10 SMP Thu Dec 3 15:14:08 EST 2020
    CPU: ARMv7 Processor [561f5811] revision 1 (ARMv7), cr=10c5387d
    CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
    OF: fdt: Machine model: WD MyCloud Mirror
    Memory policy: Data cache writeback
    Zone ranges:
      Normal   [mem 0x0000000000000000-0x000000001fffffff]
      HighMem  empty
    Movable zone start for each node
    Early memory node ranges
      node   0: [mem 0x0000000000000000-0x000000001fffffff]
    Initmem setup node 0 [mem 0x0000000000000000-0x000000001fffffff]
    CPU: All CPU(s) started in SVC mode.
    percpu: Embedded 15 pages/cpu s30028 r8192 d23220 u61440
    Built 1 zonelists, mobility grouping on.  Total pages: 129920
    Kernel command line: root=/dev/ram console=ttyS0,115200 max_loop=32
    Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
    Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
    mem auto-init: stack:off, heap alloc:off, heap free:off
    Memory: 503372K/524288K available (8692K kernel code, 475K rwdata, 2108K rodata, 1024K init, 361K bss, 20916K reserved, 0K cma-reserved, 0K highmem)
    rcu: Hierarchical RCU implementation.
    rcu:    RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
    rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
    rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
    NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
    L2C: DT/platform modifies aux control register: 0x12086302 -> 0x1a086302
    Aurora cache controller enabled, 4 ways, 256 kB
    Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a086302
    random: get_random_bytes called from start_kernel+0x324/0x4d0 with crng_init=0
    Switching to timer-based delay loop, resolution 53ns
    sched_clock: 32 bits at 18MHz, resolution 53ns, wraps every 114532461029ns
    clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 101933890472 ns
    Console: colour dummy device 80x30
    Calibrating delay loop (skipped), value calculated using timer frequency.. 37.50 BogoMIPS (lpj=187500)
    pid_max: default: 32768 minimum: 301
    Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
    Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
    CPU: Testing write buffer coherency: ok
    CPU0: thread -1, cpu 0, socket -1, mpidr 0
    Setting up static identity map for 0x100000 - 0x100060
    mvebu-soc-id: MVEBU SoC ID=0x6710, Rev=0x1
    mvebu-pmsu: Initializing Power Management Service Unit
    rcu: Hierarchical SRCU implementation.
    smp: Bringing up secondary CPUs ...
    smp: Brought up 1 node, 1 CPU
    SMP: Total of 1 processors activated (37.50 BogoMIPS).
    CPU: All CPU(s) started in SVC mode.
    devtmpfs: initialized
    VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6
    clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
    futex hash table entries: 256 (order: 2, 16384 bytes, linear)
    pinctrl core: initialized pinctrl subsystem
    NET: Registered protocol family 16
    DMA: preallocated 256 KiB pool for atomic coherent allocations
    thermal_sys: Registered thermal governor 'step_wise'
    cpuidle: using governor ladder
    cryptd: max_cpu_qlen set to 1000
    raid6: int32x8  gen()   422 MB/s
    raid6: int32x8  xor()   264 MB/s
    raid6: int32x4  gen()   477 MB/s
    raid6: int32x4  xor()   270 MB/s
    raid6: int32x2  gen()   526 MB/s
    raid6: int32x2  xor()   255 MB/s
    raid6: int32x1  gen()   497 MB/s
    raid6: int32x1  xor()   217 MB/s
    raid6: using algorithm int32x2 gen() 526 MB/s
    raid6: .... xor() 255 MB/s, rmw enabled
    raid6: using intx1 recovery algorithm
    SCSI subsystem initialized
    usbcore: registered new interface driver usbfs
    usbcore: registered new interface driver hub
    usbcore: registered new device driver usb
    pps_core: LinuxPPS API ver. 1 registered
    pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
    PTP clock support registered
    Bluetooth: Core ver 2.22
    NET: Registered protocol family 31
    Bluetooth: HCI device and connection manager initialized
    Bluetooth: HCI socket layer initialized
    Bluetooth: L2CAP socket layer initialized
    Bluetooth: SCO socket layer initialized
    clocksource: Switched to clocksource armada_370_xp_clocksource
    VFS: Disk quotas dquot_6.6.0
    VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
    FS-Cache: Loaded
    CacheFiles: Loaded
    NET: Registered protocol family 2
    tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
    TCP established hash table entries: 4096 (order: 2, 16384 bytes, linear)
    TCP bind hash table entries: 4096 (order: 3, 32768 bytes, linear)
    TCP: Hash tables configured (established 4096 bind 4096)
    UDP hash table entries: 256 (order: 1, 8192 bytes, linear)
    UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear)
    NET: Registered protocol family 1
    RPC: Registered named UNIX socket transport module.
    RPC: Registered udp transport module.
    RPC: Registered tcp transport module.
    RPC: Registered tcp NFSv4.1 backchannel transport module.
    PCI: CLS 0 bytes, default 64
    Trying to unpack rootfs image as initramfs...
    rootfs image is not initramfs (invalid magic at start of compressed archive); looks like an initrd
    Freeing initrd memory: 2620K
    Initialise system trusted keyrings
    workingset: timestamp_bits=14 max_order=17 bucket_order=3
    NFS: Registering the id_resolver key type
    Key type id_resolver registered
    Key type id_legacy registered
    Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
    FS-Cache: Netfs 'cifs' registered for caching
    Key type cifs.idmap registered
    xor: measuring software checksum speed
       arm4regs        :  1151 MB/sec
       8regs           :   902 MB/sec
       32regs          :  1085 MB/sec
    xor: using function: arm4regs (1151 MB/sec)
    async_tx: api initialized (async)
    Key type asymmetric registered
    Asymmetric key parser 'x509' registered
    Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
    io scheduler kyber registered
    armada-370-pinctrl f1018000.pin-ctrl: registered pinctrl driver
    mvebu-pcie soc:pcie@82000000: host bridge /soc/pcie@82000000 ranges:
    mvebu-pcie soc:pcie@82000000:      MEM 0x00f1040000..0x00f1041fff -> 0x0000040000
    mvebu-pcie soc:pcie@82000000:      MEM 0x00f1080000..0x00f1081fff -> 0x0000080000
    mvebu-pcie soc:pcie@82000000:      MEM 0xffffffffffffffff..0x00fffffffe -> 0x0100000000
    mvebu-pcie soc:pcie@82000000:       IO 0xffffffffffffffff..0x00fffffffe -> 0x0100000000
    mvebu-pcie soc:pcie@82000000:      MEM 0xffffffffffffffff..0x00fffffffe -> 0x0200000000
    mvebu-pcie soc:pcie@82000000:       IO 0xffffffffffffffff..0x00fffffffe -> 0x0200000000
    mvebu-pcie soc:pcie@82000000: PCI host bridge to bus 0000:00
    pci_bus 0000:00: root bus resource [bus 00-ff]
    pci_bus 0000:00: root bus resource [mem 0xf1040000-0xf1041fff] (bus address [0x00040000-0x00041fff])
    pci_bus 0000:00: root bus resource [mem 0xf1080000-0xf1081fff] (bus address [0x00080000-0x00081fff])
    pci_bus 0000:00: root bus resource [mem 0xf8000000-0xffdfffff]
    pci_bus 0000:00: root bus resource [io  0x1000-0xeffff]
    pci 0000:00:01.0: [11ab:6710] type 01 class 0x060400
    pci 0000:00:01.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
    pci 0000:00:02.0: [11ab:6710] type 01 class 0x060400
    pci 0000:00:02.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
    PCI: bus0: Fast back to back transfers disabled
    pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
    pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
    pci 0000:01:00.0: [1912:0015] type 00 class 0x0c0330
    pci 0000:01:00.0: reg 0x10: [mem 0x40000000-0x40001fff 64bit]
    pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
    PCI: bus1: Fast back to back transfers disabled
    pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
    PCI: bus2: Fast back to back transfers enabled
    pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
    pci 0000:00:01.0: BAR 8: assigned [mem 0xf8000000-0xf80fffff]
    pci 0000:00:01.0: BAR 6: assigned [mem 0xf8100000-0xf81007ff pref]
    pci 0000:00:02.0: BAR 6: assigned [mem 0xf8200000-0xf82007ff pref]
    pci 0000:01:00.0: BAR 0: assigned [mem 0xf8000000-0xf8001fff 64bit]
    pci 0000:00:01.0: PCI bridge to [bus 01]
    pci 0000:00:01.0:   bridge window [mem 0xf8000000-0xf80fffff]
    pci 0000:00:02.0: PCI bridge to [bus 02]
    mv_xor f1060800.xor: Marvell shared XOR driver
    mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
    mv_xor f1060900.xor: Marvell shared XOR driver
    mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
    Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
    printk: console [ttyS0] disabled
    f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 28, base_baud = 12500000) is a 16550A
    printk: console [ttyS0] enabled
    f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 29, base_baud = 12500000) is a 16550A
    brd: module loaded
    loop: module loaded
    scsi host0: sata_mv
    scsi host1: sata_mv
    ata1: SATA max UDMA/133 irq 37
    ata2: SATA max UDMA/133 irq 37
    libphy: Fixed MDIO Bus: probed
    libphy: orion_mdio_bus: probed
    mvneta f1074000.ethernet eth0: Using random mac address b6:31:50:d0:a3:ea
    usbcore: registered new interface driver lan78xx
    ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
    ehci-orion: EHCI orion driver
    orion-ehci f1050000.usb: EHCI Host Controller
    orion-ehci f1050000.usb: new USB bus registered, assigned bus number 1
    orion-ehci f1050000.usb: irq 35, io mem 0xf1050000
    orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
    usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
    usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
    usb usb1: Product: EHCI Host Controller
    usb usb1: Manufacturer: Linux 5.10.0-rc6+ ehci_hcd
    usb usb1: SerialNumber: f1050000.usb
    hub 1-0:1.0: USB hub found
    hub 1-0:1.0: 1 port detected
    usbcore: registered new interface driver usb-storage
    ata1: SATA link down (SStatus 0 SControl F300)
    ata2: SATA link down (SStatus 0 SControl F300)
    rtc-mv f1010300.rtc: internal RTC not ticking
    i2c /dev entries driver
    device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-devel@redhat.com
    sdhci: Secure Digital Host Controller Interface driver
    sdhci: Copyright(c) Pierre Ossman
    sdhci-pltfm: SDHCI platform and OF driver helper
    ledtrig-cpu: registered to indicate activity on CPUs
    marvell-cesa f1090000.crypto: CESA device successfully registered
    hid: raw HID events driver (C) Jiri Kosina
    usbcore: registered new interface driver usbhid
    usbhid: USB HID core driver
    NET: Registered protocol family 10
    Segment Routing with IPv6
    sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
    NET: Registered protocol family 17
    Bridge firewalling registered
    8021q: 802.1Q VLAN Support v1.8
    Key type dns_resolver registered
    Registering SWP/SWPB emulation handler
    Loading compiled-in X.509 certificates
    Key type ._fscrypt registered
    Key type .fscrypt registered
    Key type fscrypt-provisioning registered
    armada-370-pinctrl f1018000.pin-ctrl: unsupported function gpio on pin mpp54
    pinctrl core: failed to register map default (0): invalid type given
    reg-fixed-voltage: probe of regulators:regulator@2 failed with error -22
    md: Waiting for all devices to be available before autodetect
    md: If you don't use raid, use raid=noautodetect
    md: Autodetecting RAID arrays.
    md: autorun ...
    md: ... autorun DONE.
    RAMDISK: Couldn't find valid RAM disk image starting at 0.
    List of all partitions:
    0100            4096 ram0 
     (driver?)
    0101            4096 ram1 
     (driver?)
    0102            4096 ram2 
     (driver?)
    0103            4096 ram3 
     (driver?)
    0104            4096 ram4 
     (driver?)
    0105            4096 ram5 
     (driver?)
    0106            4096 ram6 
     (driver?)
                4096 ram7 
     (driver?)
    No filesystem could mount root, tried: 
     ext3
     ext2
     ext4
     vfat
     msdos
     iso9660
    Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
    ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) ]---

Here I was not able to stop the boot process with <1><1>…

    BootROM: Image checksum verification PASSED
     ** LOADER **
    U-Boot 2011.12 (Dec 24 2013 - 20:21:45) Marvell version: v2011.12 2013_Q1.2 (ALPHA U-BOOT : 1.0)
    Board: RD-88F6710_ALpha_KingsCanyon
    SoC:   MV6710 A1
    CPU:   Marvell PJ4B v7 UP (Rev 1) LE
           CPU    @ 1200 [MHz]
           L2     @ 600 [MHz]
           TClock @ 200 [MHz]
           DDR    @ 600 [MHz]
           DDR 16Bit Width, FastPath Memory Access
    DRAM:  512 MiB
    Map:   Code:            0x1fef5000:0x1ff9faac
           BSS:             0x1ffef784
           Stack:           0x1f9f4ef8
           Heap:            0x1f9f5000:0x1fef5000
    NAND:  flash id : daad
    256 MiB
    MMC:   MRVL_MMC: 0
    Bad block table found at page 131008, version 0x01
    Bad block table found at page 130944, version 0x01
    nand_read_bbt: Bad block at 0x00000e7c0000
    PEX 0: Root Complex Interface, Detected Link X1, GEN 2.0
    PEX 0.1(1): Detected No Link.
    FPU not initialized
    USB 0: Host Mode
    USB 1: Host Mode
    Modules/Interfaces Detected:
           RGMII1 Phy
           PEX0 (Lane 0)
           PEX1 (Lane 1)
           SATA0 (Lane 2)
           SATA1 (Lane 3)
    Not Marvell PHY id1 ffff id2 ffff
    Enable HD1
    �m�
    FATAL: read zero bytes from port
    term_exitfunc: reset failed for dev UNKNOWN: Input/output error

Here it was looking nice at first and then later died for an unknown reason

��H���I=5�Ź��Rj�Booting from NAND flash
High speed PHY - Version: 2.1.2 (COM-PHY-V20) 
Update PEX Device ID 0x67100
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver 4.5.0 
DDR3 Training Sequence - Ended Successfully 
Status = MV_OK
BootROM: Image checksum verification PASSED
 ** LOADER **
U-Boot 2011.12 (Dec 24 2013 - 20:21:45) Marvell version: v2011.12 2013_Q1.2 (ALPHA U-BOOT : 1.0)
Board: RD-88F6710_ALpha_KingsCanyon
SoC:   MV6710 A1
CPU:   Marvell PJ4B v7 UP
       CPU    @ 1200 [MHz]
       L2     @ 600 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 600 [MHz]
       DDR 16Bit Width, FastPath Memory Access
DRAM:  512 MiB
Map:   Code:            0x1fef5000:0x1ff9faac
       BSS:             0x1ffef784
       Stack:           0x1f9f4ef8
       Heap:            0x1f9f5000:0x1fef5000
NAND:  flash id : daad
256 MiB
MMC:   MRVL_MMC: 0
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: Bad block at 0x00000e7c0000
PEX 0: Root Complex Interface, Detected Link X1, GEN 2.0
PEX 0.1(1): Detected No Link.
FPU not initialized
USB 0: Host Mode
USB 1: Host Mode
Modules/Interfaces Detected:
       RGMII1 Phy
       PEX0 (Lane 0)
       PEX1 (Lane 1)
       SATA0 (Lane 2)
       SATA1 (Lane 3)
Not Marvell PHY id1 ffff id2 ffff
Enable HD1
Warning: egiga1 MAC addresses don't match:
Address in SROM is         00:50:43:02:00:00
Address in environment is  00:50:43:02:02:00
Hit any key to stop autoboot:  0 
NAND read: device 0 offset 0x500000, size 0x500000
 5242880 bytes read: OK
NAND read: device 0 offset 0xa00000, size 0x500000
 5242880 bytes read: OK
## Booting image at 00a00000 ...
## Booting kernel from Legacy Image at 00a00000 ...
   Image Name:   armada-370-wdmc-mirror-gen1
   Created:      2020-12-03  20:20:39 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4305717 Bytes = 4.1 MiB
   Load Address: 00008000
   Entry Point:  00008000
## Loading init Ramdisk from Legacy Image at 00f00000 ...
   Image Name:   Ramdisk
   Created:      2017-02-04  18:43:13 UTC
   Image Type:   ARM Linux RAMDisk Image (lzma compressed)
   Data Size:    2679802 Bytes = 2.6 MiB
   Load Address: 00e00000
   Entry Point:  00e00000
   Loading Kernel Image ... OK
OK
Starting kernel ...
< left out of this post because there is nothing new >
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) ]---

Here I turned the serial console logger on after turning on the NAS, you see binary data at the head.
Im a bit lost. Is this expected behavior? For all my tests I did not move the NAS and the cables. I turn the device on with a button on a long power cord. I think I can rule out vibrations.

Do you think it might be worth it trying to re-solder the connection to the pins?
Edit:
I have resoldered the pins and the issue did not disappear.

Since I am not sure what is not working correctly I have to debug the individual parts. There are some oddities with the Raspberry Pi. It has 2 UARTs, a good one (PL011) and a worse one (mini UART). Usually the PL011 is tied to bluetooth on the raspberry 3 and the GPIO pins are tied to the mini UART. The latter is bound to the VPU clock speed and such cannot keep a stable baud rate.

The particular deficiencies of the mini UART compared to a PL011 are :

    No break detection
    No framing errors detection
    No parity bit
    No receive timeout interrupt
    No DCD, DSR, DTR or RI signals

My first step now is to try to have access to PL011 as /dev/serial0 because only /dev/serial0 is bound to GPIO 14 and 15.

Then I want to short connect RX and TX on the PI because that should tell me if I can send and receive via any of the serial consoles in a stable fashion.

Unfortuantely something went wrong along that path and I have to set up the pi again.

Seems not to be the software stack - I have the same issue with a freshly setup pi, either using mini UART or PL011 I seem to not receive any data any longer. This might be an indication that I somehow have bricked the NAS or the raspberry pi.

Shortcutting RX and TX does not seem to transmit anything but I am still not sure how to ‘send’. So I plugged in a cable to the PIs RX and touched several times the 3.3V+ with the other end. I get some feedback. For me that shows that the RX on the PI works. The Tx part is still weird.

However, I do not see any message when turning on the NAS any longer. Since the Nas’ Tx is connected to the pi’s Rx, doent that mean the NAS is dead?

Any idea?

I’m really no expert in this but from what I understand is that UART has Ground, Send, Receive and Power. A signal is understood by looking at the high/low changes in time. High and low is only known because there needs to be a common GND.

So for testing whether the NAS still sends (NAS TX - TXn) to the Serial (PI RX - RXp) I need GND and connect TXn with RXp. In this setting nothing is being displayed.

Since the voltmeter detects changes in electric potential between TXn and GND NAS (GNDn) when I turn on the NAS I still have hope, though.

As written above connecting TXn-RXp and GNDn-GNDp does not show anything in the serial console. Out of curiosity I have tried TXn-GNDp and GNDn-RXp and was expecting the same but curiously I see binary data transmitted. Is this expected? And what does it tell me?

I will have a dedicted UART reader and a new PI in some days and will continue investigation then.

Just in case anyone has the same question: My UART on the Raspberry is broken. PI comes with wiringpi which has a small test program that tests if RxD and TxD work when they are short.

wget https://github.com/WiringPi/WiringPi/blob/master/examples/serialTest.c
gcc serialTest.c -l wiringPi -o serialtest
./serialtest 
Out:   0: 
Out:   1: 
Out:   2: 
Out:   3: 
...

If send and receive works you get something like this (probably the digits you send, though)

155 -> 191 ->  51 ->  51 ->  51 ->  51 -> 229 -> 235 ->   0 ->  93 -> 164 -> 218 ->  58 -> 170 -> 250 -> 123 -> 221 -> 117 -> 229 -> 235 ->   0
Tx -> Rx
Rx -> Tx
Gnd -> Gnd
5v/vcc - not used.

You can shor Rx and Tx on device before start for force stop boot. Resotore connection to normal after ~10-15 seconds and see if it helps.

Trash in console at start - is normal (Special byte-mode for upload bootloader via uart).

Hit any key to stop autoboot: 0 ← Here need to press “1” for stop autoboot. Or 1-2seconds before this line show.

Seems like kernel can’t find ramdisk or he is damaged/unsupported format.

Turns out the raspi 3 UART Tx was broken. I was able to receive but not send using the raspi. Even receiving looked broken. I have tested that with a cheap cp210x that I attached via USB to the same pi.

Now I can see the boot process without any issues and I am able to reach the marvell prompt. Great. Now I can start playing again :slight_smile:

That worked fine. My NAS is back to life and I face a weird concert of blinking red LEDs.
Thank you @Fox_exe

I also bought a new Raspberry Pi 4. I have just used the sdcard from the Raspberry Pi 3 and such have the same settings, using the PL011 as serial0 being connected to GPIO 14 and 15.

$ raspi-gpio get 14,15
GPIO 14: level=1 fsel=4 alt=0 func=TXD0 pull=NONE
GPIO 15: level=1 fsel=4 alt=0 func=RXD0 pull=UP

$ ls -la /dev/serial*
lrwxrwxrwx 1 root root  7 Dec  9 13:54 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root  5 Dec  9 13:54 /dev/serial1 -> ttyS0

I can confirm that the new raspberry Pi works as expected and data can be sent and received via these pins. So my pi3 is definitively broken and the method will also work with the UART from the raspberry pi.

Weird. Using your kernel or mine the system hangs at

Uncompressing Linux... done, booting the kernel.

I have no idea what the issue is and how I can workaround it. Here is the full boot log:

BootROM 1.08
Booting from NAND flash
High speed PHY - Version: 2.1.2 (COM-PHY-V20) 
Update PEX Device ID 0x67100
High speed PHY - Ended Successfully
                                   DDR3 Training Sequence - Ver 4.5.0 
DDR3 Training Sequence - Ended Successfully 
Status = MV_OK
BootROM: Image checksum verification PASSED

 ** LOADER **


U-Boot 2011.12 (Dec 24 2013 - 20:21:45) Marvell version: v2011.12 2013_Q1.2 (ALPHA U-BOOT : 1.0)

Board: RD-88F6710_ALpha_KingsCanyon
SoC:   MV6710 A1
CPU:   Marvell PJ4B v7 UP (Rev 1) LE
       CPU    @ 1200 [MHz]
       L2     @ 600 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 600 [MHz]
       DDR 16Bit Width, FastPath Memory Access
DRAM:  512 MiB

Map:   Code:            0x1fef5000:0x1ff9faac
       BSS:             0x1ffef784
       Stack:           0x1f9f4ef8
       Heap:            0x1f9f5000:0x1fef5000

NAND:  flash id : daad
256 MiB
MMC:   MRVL_MMC: 0
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: Bad block at 0x00000e7c0000
PEX 0: Root Complex Interface, Detected Link X1, GEN 2.0
PEX 0.1(1): Detected No Link.
FPU not initialized
USB 0: Host Mode
USB 1: Host Mode
Modules/Interfaces Detected:
       RGMII1 Phy
       PEX0 (Lane 0)
       PEX1 (Lane 1)
       SATA0 (Lane 2)
       SATA1 (Lane 3)
Not Marvell PHY id1 ffff id2 ffff
Enable HD1
Enable HD2
Net:   egiga1
Warning: egiga1 MAC addresses don't match:
Address in SROM is         00:50:43:02:00:00
Address in environment is  00:50:43:02:02:00

Hit any key to stop autoboot:  0 
Marvell>> dhcp; setenv serverip 192.168.178.34; tftp 0xa00000 uImage; tftp 0xf00000 uRamdisk; bootm 0xa00000 0xf00000
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 42
*** Unhandled DHCP Option in OFFER/ACK: 158
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 42
*** Unhandled DHCP Option in OFFER/ACK: 158
DHCP client bound to address 192.168.178.53
Using egiga1 device
TFTP from server 192.168.178.34; our IP address is 192.168.178.53
Filename 'uImage'.
Load address: 0xa00000
Loading: #################################################################
         #################################################################
         #################################################################
         ##########################################################
done
Bytes transferred = 3702016 (387d00 hex)
Using egiga1 device
TFTP from server 192.168.178.34; our IP address is 192.168.178.53
Filename 'uRamdisk'.
Load address: 0xf00000
Loading: #################################################################
         #################################################################
         #####################################################
done
Bytes transferred = 2679866 (28e43a hex)
## Booting image at 00a00000 ...
## Booting kernel from Legacy Image at 00a00000 ...
   Image Name:   armada-370-wdmc-mirror-gen1
   Created:      2018-02-06  14:23:51 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3701952 Bytes = 3.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00f00000 ...
   Image Name:   Ramdisk
   Created:      2017-02-04  18:43:13 UTC
   Image Type:   ARM Linux RAMDisk Image (lzma compressed)
   Data Size:    2679802 Bytes = 2.6 MiB
   Load Address: 00e00000
   Entry Point:  00e00000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Were uImage is this and uRamdisk is this.

The statement above was not correct and it took me some time to find out the reason. Please see the second next comment to read what has happened.

Seems like the original uImage and uRamdisk are working. I can work from there.

Kernel 4.15 was the last kernel having shipped the PXA3xx driver (CONFIG_MTD_NAND_PXA3xx). It was replaced with the marvell_nand driver (CONFIG_MTD_NAND_MARVELL). Unfortunately this led to a regression such that /dev/mtdblock* devices didn’t get populated.

Because I had not realized that the /dev/mtdblock* devices were missing flashing a working kernel like the one linked 2 statements above from @Fox_exe (yes, it is working fine!) led to boot issues: dd if=/dev/zero of=/dev/mtdblock1 led to creating a new file called mtdblock1 instead of flashing over that device. I realized that because the dd process was much qicker than usual.

The kernel team already realized that this is a regression and will decide on the next steps.

I was able to compile the kernel v.5.10.109 and to use the device with Debian Bullseye and OMV.
I published the full guide on GitHub - gisab/WDMC-Ex2: Steps to update your Linux Kernel for WD My Cloud Ex2
#WDUserRewards

1 Like