| Electronics > Repair |
| Drobo B810i NAS half bricked after failed firmware update |
| << < (4/5) > >> |
| JimKnopf:
I managed to boot Firmware 1.3.5 and getting Drobo-Dashboard to recognize the device. The App couldn't find an update server |O and manual update failed for now. The solution with the wired-out SPI cmos flash and Pi-zero as Wifi-SSD is perfect. Easy to handle. |
| JimKnopf:
I don't know why but i can't reproduce recognizing the Drobo by the Dashboard. I will give up on that device. I found out some things, maybe it will help others. The Marvell U-Boot on that device, which is located in the CMOS flash chip doesn't have the typical U-Boot Magic Number (27 05 19 56) and CRC32 checksum in the header (Byte 4 to 7). It starts with 5A. The ARMADA-XP-Functional-SpecDatasheet.pdf tells 0x5A = Boot from SPI/NOR flash. Have a look at the SpecDatasheet for more information. If you corrupt the CMOS flash data, don't worry. There is a file on the internal USB-SSD called UBHW.bin (and the header file UBHW.hdr for it). Most probably UBHW means U-Boot Heatwave, a hint to the board name i guess. The binary contains the U-Boot data without environment data. The individual env settings are stored at 0xd0000 to 0xdffff. If you dump the CMOS flash data, you can cut off the zeros after 0xe0000. The file is less than 1 MB. To start the drobo, you need just LxImage and vxWorks files on the USB-SSD. Thats it. I attached both log files (linux side and vxworks side) from last sunday when the drobo was recognized. You can see in the logfile what files i had on the USB-SSD. The reason why i give up on the device is, it only starts with release 1-3-5 properly. The 2-0-0 and 2-0-1 releases won't start up. I think either vxWorks or Lximage (LXKI Linux Kernel Image) has wrong version to interact with the other side. The LxImage starts with this mtd settings: --- Code: ---INFO: Found cfi_flash_0 0 - base 0xd8000000, size 0x8000000, bus 2 INFO: flashInfoFill - Found 1 Flash Devices INFO: flash_map_init - detected 1 devices MTD: Initialize the cfi_flash_0 device at address 0xd8000000 INFO: Io remapped successfully - phy addr = 0xd8000000, virt addr = 0xd9000000 INFO: Using cfi_probe to probe cfi_flash_0 at address 0xd8000000, size 0x8000000, width 2m cfi_flash_0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002801 Amd/Fujitsu Extended Query Table at 0x0040 Amd/Fujitsu Extended Query version 1.5. number of CFI chips: 1 - detected OK 6 cmdlinepart partitions found on MTD device cfi_flash_0 Creating 6 MTD partitions on "cfi_flash_0": 0x000000000000-0x000000100000 : "nor_hdr" 0x000000100000-0x000000400000 : "var" 0x000000400000-0x000002200000 : "rfs0" 0x000002200000-0x000004000000 : "rfs1" 0x000004000000-0x000006000000 : "rfs2" 0x000006000000-0x000008000000 : "rfs3" - OK. --- End code --- That is a U-Boot env setting: --- Code: ---LxMtd=mtdparts=cfi_flash_0:1m@0m(nor_hdr),3m@1m(var),30m@4m(rfs0),30m@34m(rfs1),32m@64m(rfs2),32m@96m(rfs3) --- End code --- And there is additionally this line: --- Code: ---LxRoot=rootfstype=jffs2 root=/dev/mtdblock2 rw --- End code --- With this settings, release 1-3-5 starts, but has an issue with rfs0 and therefore it can't mount /bin and /etc: --- Code: ---[1970-01-01,00:00:12.132085843] 10: INFO: Mounting /bin as rw mount: mounting /tmp/bin on /bin failed: No such device [1970-01-01,00:00:12.166910723] 10: ERROR: Failed to mount /bin as rw [1970-01-01,00:00:12.185068643] 10: INFO: Mounting /etc as rw mount: mounting /tmp/etc on /etc failed: No such device [1970-01-01,00:00:12.219105483] 10: ERROR: Failed to mount /etc as rw --- End code --- The whole logfile has errors like this: --- Code: ---chmod: /etc/monitrc: Read-only file system awk: /etc/resolv.conf: No such file or directory chmod: /etc/monitrc: Read-only file system --- End code --- If i change --- Code: ---LxRoot=rootfstype=jffs2 root=/dev/mtdblock2 rw --- End code --- to --- Code: ---LxRoot=rootfstype=jffs2 root=/dev/mtdblock3 rw --- End code --- It starts without this Read-only errors. But it didn't recognized the drobo. I also could set --- Code: ---setenv LxForceRootFS yes --- End code --- It will force to use mtd3, no Read-only errors, but still not recognized. When the drobo was recognized, it had this message in my logfile: --- Code: ---Sun Jan 14 13:37:44 2024: tCoreCtrl: setLinuxCommonInfo: SUCCESS: Setting Serial Number Config. New serial number = dra160401c00313 Sun Jan 14 13:37:44 2024: tCoreCtrl: Unexpected reboot - generate crash log from last boot logs Sun Jan 14 13:37:44 2024: tCoreCtrl: copy iscsitgtlog.old to iscsitgtlog.crash Sun Jan 14 13:37:59 2024: tCoreCtrl: iSCSI stack ENABLE message received Sun Jan 14 13:37:59 2024: tCoreCtrl: Initializing network settings Sun Jan 14 13:37:59 2024: tCoreCtrl: InitializeNetworConfigEx: Called Sun Jan 14 13:38:01 2024: tCoreCtrl: iscsiTgtPortalUpdateIPAddress: Old Ipaddr: 0:0:0:0 Sun Jan 14 13:38:01 2024: tCoreCtrl: iscsiTgtPortalUpdateIPAddress: Updated Portal Id: 0x11dd38 ipaddress length: 4 Sun Jan 14 13:38:01 2024: tCoreCtrl: iscsiTgtPortalUpdateIPAddress: New Ipaddr: 169:254:4:0 Sun Jan 14 13:38:01 2024: tCoreCtrl: iscsiTgtPortalUpdateIPAddress: Old Ipaddr: 0:0:0:0 Sun Jan 14 13:38:01 2024: tCoreCtrl: iscsiTgtPortalUpdateIPAddress: Updated Portal Id: 0x11df30 ipaddress length: 4 Sun Jan 14 13:38:01 2024: tCoreCtrl: iscsiTgtPortalUpdateIPAddress: New Ipaddr: 169:254:5:0 Sun Jan 14 13:38:01 2024: tCoreCtrl: File /var/discWhiteList not found. Allowing all hosts for discovery. Sun Jan 14 13:38:01 2024: tCoreCtrl: Starting Discovery!! Sun Jan 14 13:38:01 2024: tIscsiMgr: Setting SO_BINDTODEVICE, for device eth0 Sun Jan 14 13:38:01 2024: tCoreCtrl: *************** sending stack UP across icore *************** Sun Jan 14 13:38:01 2024: tIscsiMgr: Setting SO_BINDTODEVICE, for device eth1 Sun Jan 14 13:38:01 2024: tDiscListen: Discovery: Listener loop starting Sun Jan 14 13:38:01 2024: tDiscAgent: Discovery: Agent starting Sun Jan 14 13:38:02 2024: tDiscListen: Added client info for 192.168.10.43:65359 (flags 0x3e, 0x3e) Sun Jan 14 13:38:02 2024: tDiscListen: Client info received from host: IP: 192.168.10.43 Port: 65359 (iqn.1991-05.com.microsoft:sls2 2b0aa8c0-32646) Sun Jan 14 13:38:02 2024: tDiscListen: QueueWaitingHost: Found host 192.168.10.43 on port 65359 Sun Jan 14 13:38:05 2024: tEMPDConn00000: EMPDConnection::Starting thread tEMPDConn00000 and clientID SLS231727.0000028690 Sun Jan 14 13:38:05 2024: tEMPDConn00000: EMPDListener::AddConnection - for SLS231727 NEW (192.168.10.43 7876 via ) Sun Jan 14 13:38:05 2024: tHBConn00000: HBConnection: Starting thread tHBConn00000 and clientID SLS231727.0000028690 Sun Jan 14 13:38:05 2024: tHBConn00000: HBConnection::Start- The Unique ID received is : 0000028690 Sun Jan 14 13:38:05 2024: tHBConn00000: HBConnection::Start- The host ID received is : SLS231727 Sun Jan 14 13:38:05 2024: tHBConn00000: HBConnection::Start- Received new connection!! Sun Jan 14 13:38:05 2024: tHBConn00000: HBConnection::Start- Now starting to send heart beat messages - --- End code --- I tried Drobo-Dashboard 3.5.0 and the older 2.6.4 on Windows. If i manually set the IP for the Drobo, it never find it. There is always an error message about incomplete header like this: --- Code: ---chmod: /etc/monitrc: Read-only file system chmod: /etc/monitrc: Read-only file system chmod: /etc/monitrc: Read-only file system Thu Jan 18 15:23:24 2024: tEMPDConn00000: EMPDConnection: did not receive complete header! (recv len 0, hdr len 47, error 0) Thu Jan 18 15:23:24 2024: tEMPDConn00000: EMPDConnection: Error 0 receiving login header. Thu Jan 18 15:23:24 2024: tEMPDConn00000: EMPDConnection: Cleaning up thread tEMPDConn00000 for host with UID Thu Jan 18 15:23:24 2024: tEMPDConn00000: HBListener::SetupCleanup for Thu Jan 18 15:23:24 2024: tEMPDConn00000: HBListener::SetupCleanup for . Done Thu Jan 18 15:23:24 2024: tEMPDConn00000: EMPDListener::RemoveConnection - for chmod: /etc/monitrc: Read-only file system chmod: /etc/monitrc: Read-only file system chmod: /etc/monitrc: Read-only file system --- End code --- I sniffed the packet with wireshark but couldn't find any suspicious fault in the data. I don't have a working datastream for comparison. I also tried tricks i found somewhere like using nc to redirect port 5002 to the drobo with this command without success: --- Code: ---nc -lvu 5002 | nc 192.168.10.72 (Drobo ip) --- End code --- |
| JimKnopf:
I tried one last thing because of the "Read-only file system" error message on mtdblock1. The 128 MB NOR-flash chip (Spansion S29GL01GS10TFI01) is on the backside of the mainboard. The internal USB-SSD has all the system files on it like vxWorks, the LxImage that starts every time from USB-SSD and LXFS which is a JFFS2 filesystem. I thought, what if i erase the NOR-flash. Maybe something is wrong with the data and therefore mtdblock2 can't be mounted. I desoldered the 56 pin NOR-flash and dumped the data using a RT809H programmer and compard the data with my two memory dumps i did earlier using openocd. The openocd dumps had 3 JFFS2 sections. The dump from RT809H programmer had 7 JFFS2 sections. After erasing the chip, the Linux side didn't came up because it couldn't init the NOR-flash. --- Code: --- 2.164160] md: Waiting for all devices to be available before autodetect [ 2.170982] md: If you don't use raid, use raid=noautodetect [ 2.177276] md: Autodetecting RAID arrays. [ 2.181399] md: Scanned 0 and added 0 devices. [ 2.185857] md: autorun ... [ 2.188657] md: ... autorun DONE. [ 2.215786] JFFS2 notice: (1) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. [ 2.231091] VFS: Mounted root (jffs2 filesystem) on device 31:3. [ 2.237291] Freeing init memory: 240K [ 2.241015] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance. [ 2.253499] CPU0: stopping [ 2.256215] Backtrace: [ 2.258701] [<80011acc>] (dump_backtrace+0x0/0x10c) from [<8055958c>] (dump_stack+0x18/0x1c) [ 2.267166] r7:8074bf8c r6:fbb21000 r5:00000000 r4:807958dc [ 2.272899] [<80559574>] (dump_stack+0x0/0x1c) from [<800132dc>] (handle_IPI+0x108/0x184) [ 2.281106] [<800131d4>] (handle_IPI+0x0/0x184) from [<80008394>] (do_IPI+0x10/0x14) [ 2.288873] r5:60000013 r4:8000f090 [ 2.292488] [<80008384>] (do_IPI+0x0/0x14) from [<8055c8b4>] (__irq_svc+0x34/0xe8) [ 2.300082] Exception stack(0x8074bf58 to 0x8074bfa0) [ 2.305150] bf40: 0000001f 807562fc [ 2.313357] bf60: 8074bf90 80018ea4 8074a000 8075c36c 807956c4 8056721c 2000406a 562f5842 [ 2.321565] bf80: 00000000 8074bfbc 8074bfa0 8074bfa0 8000ec5c 8000f090 60000013 ffffffff [ 2.329774] [<8000f008>] (cpu_idle+0x0/0xcc) from [<8054ef34>] (rest_init+0x64/0x7c) [ 2.337541] r7:8075c364 r6:80738a40 r5:00000000 r4:80756e84 [ 2.343274] [<8054eed0>] (rest_init+0x0/0x7c) from [<8070c89c>] (start_kernel+0x204/0x240) [ 2.351569] [<8070c698>] (start_kernel+0x0/0x240) from [<20008040>] (0x20008040) [ 2.358990] CPU2: stopping [ 2.361705] Backtrace: [ 2.364184] [<80011acc>] (dump_backtrace+0x0/0x10c) from [<8055958c>] (dump_stack+0x18/0x1c) [ 2.372648] r7:b1119fac r6:fbb21000 r5:00000002 r4:807958dc [ 2.378377] [<80559574>] (dump_stack+0x0/0x1c) from [<800132dc>] (handle_IPI+0x108/0x184) [ 2.386585] [<800131d4>] (handle_IPI+0x0/0x184) from [<80008394>] (do_IPI+0x10/0x14) [ 2.394351] r5:60000013 r4:8000f090 [ 2.397965] [<80008384>] (do_IPI+0x0/0x14) from [<8055c8b4>] (__irq_svc+0x34/0xe8) [ 2.405558] Exception stack(0xb1119f78 to 0xb1119fc0) [ 2.410626] 9f60: 00000021 807562fc [ 2.418834] 9f80: b1119fb0 80018ea4 b1118000 8075c36c 807956c4 8056721c 2000406a 562f5842 [ 2.427042] 9fa0: 00000000 b1119fdc b1119fc0 b1119fc0 8000ec5c 8000f090 60000013 ffffffff [ 2.435251] [<8000f008>] (cpu_idle+0x0/0xcc) from [<8055698c>] (secondary_start_kernel+0x140/0x164) [ 2.444324] r7:807958e4 r6:10c03c7d r5:00000015 r4:00000004 [ 2.450050] [<8055684c>] (secondary_start_kernel+0x0/0x164) from [<20556494>] (0x20556494) [ 2.458340] r5:00000015 r4:5112006a [ 2.461949] shared_mem_panic_event: Kernel panic event handler called. Notifying VxWorks Core of Kernel panic. --- End code --- As you can see in the image, there are 16 Bytes (0x0 - 0x1f) at the beginning before a large empty block. After inserting the 16 bytes (i desoldered/resoldered the chip six times) the system started with errors, missing Magic Bytes at specific offset addresses. It didn't work this way. I put all dumped data back on the NOR-flash to get the system status i already had before. |
| Mudgho:
I found this thread interesting but sadly I don't have much to add in terms of trying to fix your bricked unit. I did however recently come across a 4-bay Drobo gen 3 USB (DAS). I dont really have any use for the beyondraid and was thinking of possibly just making a JBOD enclosure out of it but looking around it seems its quite the task. Given your experience with the firmware things youve done I was wondering if you think its doable. By doable I mean can it be done using the current hardware. I'm not as versed as you with these things but I do like tinkering with stuff. |
| JimKnopf:
@Mudgho This is not a PC. It's a special piece of hardware and the manufacturer is gone. You need driver blobs to get the hardware working. I'm not a Drobo expert. I think it will be difficult to reach your goal. |
| Navigation |
| Message Index |
| Next page |
| Previous page |