• June 20, 2019, 07:08:52 AM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  


This Forum Beta is ONLY for registered owners of D-Link products in the USA for which we have created boards at this time.

Pages: 1 2 3 [4]

Author Topic: DNS 343 Firmware upgarade to 1.05. Now NAS will no longer boot, not accessible  (Read 25870 times)


  • Level 1 Member
  • *
  • Posts: 24

In summing up, I would like to offer some observations on this matter, if I may, even though I do not understand anything technical about this, except common sens:

- There has to be a way to load the firmware into the DNS-343. How was it loaded into it at time of manufacture when the board was new/empty?
- Also, when a unit is still under warranty how does D-Link fix it? They must have a shop or know of a shop that does their repair work in the US as I am sure they do not sent it to Asia for repair purposes.
_ Mine is no longer under warranty and I offered to pay for repairing my unit - but maybe this is not a cost conscious observation
- Furthermore, in many forums sooner or later a factory rep joins into the fray and offers suggestions if not concrete help.
- Maybe D-Link is not interested in existing customers (my router is also a D-Link) as the response I received from them directly to my pleas were just boilerplate.

Again, as I write this, a new post arrived from JavaLawyer and that seems to be the final word on this
"Warning - while you were typing a new reply has been posted. You may wish to review your post."

Many thanks for all your effort in trying to help me fix a unit that used to work great for many years and only because I tried to update it lost my DNS343. What a pity!

« Last Edit: May 12, 2014, 01:38:28 PM by giftmugs »


  • BETA Tester
  • Level 15 Member
  • *
  • Posts: 12190
  • D-Link Global Forum Moderator
    • FoundFootageCritic

Thank you very much for your post and effort in helping me recuperate an otherwise fully functioning NAS drive.....
Why did I have to update the firmware, why did I listen to the D-Link Blog? Yes, why, indeed??
There was nothing wrong with my 343.

I personally do not perform a firmware upgrade unless there's a substantial upside to be gained that offsets the potential risk. When it comes to storage products, I'm very skittish about taking the plunge as my data is irreplaceable. Conversely, I'm more easily swayed to upgrade the FW in my network cameras, even if the improvements are minor, since the risk of failure is one I can live with.
Find answers here: D-Link ShareCenter FAQ I D-Link Network Camera FAQ
There's no such thing as too many backups FFC


  • Level 1 Member
  • *
  • Posts: 24

I only ran the update because D-Link sent me an e-mail blog suggesting it.
Otherwise I would not even have known that I  can update.


  • Level 8 Member
  • ***
  • Posts: 1438

This is the thing I was just talking about!

The DNS-343 uses the same chipset as the DNS323.

The serial headers are JP2 and JP4 with, I think JP2 being the one we want (the other is the port for the OLED controller)

Pinout:  (pin one has the square solder pad)

pin 1 - +3.3v
pin 2 - RX
pin 3 - TX
pin 4 - GND

The signal levels at the NAS end are 3.3v which have to be level shifted to and from the PC (use a MAX232 based level shifter).

The terminal program should be set at 115200-8-N

That is the hardware defined

Now as per the dns323.kood.org/dns-343 wiki page the U-boot information is as follows:


 ** LOADER **

U-Boot 1.1.1 (Apr  1 2009 - 18:02:07) Marvell version: 2.2.2.Gandolf.02

U-Boot code: 00200000 -> 0026FFF0  BSS: -> 0027BC8C

Soc: 88F5281 D0 (DDR1)
CPU running @ 500Mhz
SysClock = 166Mhz , TClock = 166Mhz

DRAM CS[0] base 0x00000000   size 128MB
DRAM Total size 128MB
[16384kB@ff000000] Flash: 16 MB
Addresses 4M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (4M - 3M): Done

CPU : ARM926 (Rev 0)
Streaming disabled
VFP initialized to Run Fast Mode.

USB 0: host mode
CPU: Write allocate enabled
Net:   egiga0 [PRIME]
Hit any key to stop autoboot:  0
Marvell>>  printenv
bootargs=root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none
bootcmd=bootm FF040000 FF1C0000
bootargs_root=root=/dev/nfs rw
standalone=fsload 0x400000 $(image_name);setenv bootargs $(bootargs) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end); bootm 0x400000;

Environment size: 835/4092 bytes

The other information provided by sysinfo is:


Processor       : ARM926EJ-S rev 0 (v5l)
BogoMIPS        : 498.07
Features        : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 0
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 32768
I assoc         : 1
I line length   : 32
I sets          : 1024
D size          : 32768
D assoc         : 4
D line length   : 32
D sets          : 256

Hardware        : Feroceon
Revision        : 0000
Serial          : 0000000000000000


MemTotal:       126836 kB
MemFree:         73700 kB
Buffers:         28108 kB
Cached:          11668 kB
SwapCached:          0 kB
Active:           9248 kB
Inactive:        35364 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:              20 kB
Writeback:           0 kB
AnonPages:        4864 kB
Mapped:           1540 kB
Slab:             7140 kB
SReclaimable:      848 kB
SUnreclaim:       6292 kB
PageTables:        140 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:     63416 kB
Committed_AS:    12168 kB
VmallocTotal:   385024 kB
VmallocUsed:     18016 kB
VmallocChunk:   360444 kB

DMESG Output

Linux version (jack@SWTEST1) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #4 Fri Jan 22 11:02:54 CST 2010
CPU: ARM926EJ-S [41069260] revision 0 (ARMv5TEJ), cr=00053177
Machine: Feroceon
Using UBoot passing parameters structure
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 32768
  DMA zone: 256 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 32512 pages, LIFO batch:7
  Normal zone: 0 pages used for memmap
CPU0: D VIVT write-back cache
CPU0: I cache: 32768 bytes, associativity 1, 32 byte lines, 1024 sets
CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
Built 1 zonelists.  Total pages: 32512
Kernel command line: root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB 0MB 0MB 0MB = 128MB total
Memory: 117248KB available (2876K code, 193K data, 120K init)
Calibrating delay loop... 498.07 BogoMIPS (lpj=2490368)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
Sys Clk = 166666667, Tclk = 166666667

CPU Interface
SDRAM_CS0 ....base 00000000, size 128MB
SDRAM_CS1 ....base 10000000, size 256MB
SDRAM_CS2 ....base 20000000, size 256MB
SDRAM_CS3 ....base 30000000, size 256MB
PEX0_MEM ....base e0000000, size 128MB
PEX0_IO ....base f2000000, size   1MB
PCI0_MEM ....base e8000000, size 128MB
PCI0_IO ....base f2100000, size   1MB
INTER_REGS ....base f1000000, size   1MB
DEVICE_CS0 ....no such
DEVICE_CS1 ....no such
DEVICE_CS2 ....no such
DEV_BOOCS ....base ff000000, size  16MB

  Marvell Development Board (LSP Version 3.0.5_NAS_GDP_p9)-- DB-88F5X81-DDR1-A  Soc: 88F5281 D0
 Detected Tclk 166666667 and SysClk 166666667
Marvell USB EHCI Host controller #0: c112c600
PCI: bus0: Fast back to back transfers disabled
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Time: orion_clocksource clocksource has been installed.
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 9328K
RTC registered
Use IDMA channels 2 and 3 for enhancing the following function:
  o Copy From/To user space operations.
  o memcpy() and memmove() operations.
  o memzero() operations.
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
squashfs: version 3.3 (2007/10/31) Phillip Lougher
squashfs: LZMA suppport for slax.org by jro
io scheduler noop registered
io scheduler anticipatory registered (default)
Serial: 8250/16550 driver $Revision: $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 3) is a 16550A
serial8250.0: ttyS1 at MMIO 0xf1012100 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 25600K size 1024 blocksize
loop: module loaded
Marvell Ethernet Driver 'mv_ethernet':
  o Uncached descriptors in DRAM
  o DRAM SW cache-coherency
  o TCP segmentation offload enabled
  o Checksum offload enabled
  o Marvell ethtool proc enabled
  o Rx desc: 128
  o Tx desc: 256
  o Loading network interface 'egiga0'
PCI: enabling device 0000:00:01.0 (0140 -> 0143)
scsi0 : Marvell SCSI to SATA adapter
scsi1 : Marvell SCSI to SATA adapter
scsi2 : Marvell SCSI to SATA adapter
scsi3 : Marvell SCSI to SATA adapter
flash VppMin = "0" , VppMax = "0"
cfi_flash_0: Found 1 x16 devices at 0x0 in 8-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
cfi_flash_0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
Creating 5 MTD partitions on "cfi_flash_0":
0x00000000-0x00020000 : "MTD1"
0x00020000-0x00040000 : "MTD2"
0x00040000-0x001c0000 : "Linux Kernel"
0x001c0000-0x00f80000 : "File System"
0x00f80000-0x01000000 : "u-boot"
ehci_marvell ehci_marvell.4523: Marvell Orion EHCI
ehci_marvell ehci_marvell.4523: new USB bus registered, assigned bus number 1
ehci_marvell ehci_marvell.4523: irq 17, io base 0xf1050100
ehci_marvell ehci_marvell.4523: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
mice: PS/2 mouse device common for all mice
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
raid6: int32x1     30 MB/s
raid6: int32x2     48 MB/s
raid6: int32x4     53 MB/s
raid6: int32x8     48 MB/s
raid6: using algorithm int32x4 (53 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: measuring checksumming speed
   arm4regs  :   429.600 MB/sec
   8regs     :   330.000 MB/sec
   32regs    :   513.600 MB/sec
raid5: using function: 32regs (513.600 MB/sec)
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 120K
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
usbcore: registered new interface driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
egiga0: mac address changed
egiga0: Ilegal MTU value 9000,  rounding MTU to: 9004
egiga0: change mtu 1500 (buffer-size 1520) to 9004 (buffer-size 9024)
egiga0: link down
egiga0: link up, full duplex, speed 1 Gbps
usbcore: deregistering interface driver usblp
No found HD

And the standard access to U-Boot is space + 1

Need I say more?


  • Level 1 Member
  • *
  • Posts: 24


Thank you for the very detailed tech info as well as the previous post about tech service in general, both of which are greatly appreciated.

Since I am not able to do the actual fixing of my 343, would I be able to use the existing 4 HHD's just as they are (from the now dead 343 box) and insert them into a new 343 box and go on with my life?

I read everywhere that any disk inserted anew into a 343 box will automatically be formatted no matter what.
Is there a way around this automatic formatting or do I need to purchase new HHD disks and copy to them from the old disks via Ext2 to my PC and then back to the "New"  343?


  • Level 8 Member
  • ***
  • Posts: 1438

From the beginning of this topic it appears as that you have two RAID 1 sets (this is how we setup our unit we sold).

If this is the case then you only need two new disks at the most and if one of the arrays was a backup of the other that can be reduced to one.

The above is based on the fact that the pair of disks in a RAID 1 array both carry the exact same information hence the rebuilding of the array if a disk dies is little more than the unit copying the contents of the remaining disk to the new one.

If that is indeed your setup then it will be a simple matter of plugging three of the original disks with the new one into the replacement unit.  Try and keep one of the RAID arrays together just to check if it will accept it as a valid array, if it does you are up and running.  If it doesn't just setup the two RAID 1 arrays put the reserved disk into a USB/SATA caddy or adapter, plug it into a PC that has been booted from a live Linux CD and start copying your data over.

Once the data transfer is complete setup the unit to backup the primary array to the secondary array and you are back to where you were before all this happened.  You also have an added bonus if you used a USB/SATA caddy that you have have a third backup of your data  (as an aside, we have three separate backup units for every primary unit and an off site storage array for backup as well, but then we have clients data to look after as well as our own).


  • BETA Tester
  • Level 15 Member
  • *
  • Posts: 12190
  • D-Link Global Forum Moderator
    • FoundFootageCritic

Ivan, correct me if I'm wrong, but hypothetically speaking, wouldn't he also be able to "possibly" drop one of the RAID-1 arrays into a DNS-323 (if he can come across a unit) since the underlying architecture is the same?
Find answers here: D-Link ShareCenter FAQ I D-Link Network Camera FAQ
There's no such thing as too many backups FFC


  • Level 1 Member
  • *
  • Posts: 24

Thanks for your reply.

Yes, Ivan, you're correct my "broken" unit had two RAID 1 sets.

However I am still puzzled and before I make any mistakes I would need to know if any disk that is inserted into the NS-343 will automatically be formatted. 

Since any new 343 unit would have no disks installed at the beginning and if I now insert one disk, that disk will be automatically formatted. Then what happens if I insert one of the disk form my "broken" 343? It will be formatted before I can copy it.

Could you clarify this for my, please?
Thank you.


  • Level 8 Member
  • ***
  • Posts: 1438

I will try and answer but please remember we no longer have a 343 to test this with.

For a start as JavaLawyer says, in theory it should be possible to just plug in the two RAID 1 arrays and they should work BUT, and this is a very large but, a lot depends on the firmware revision of the old unit and the replacement unit.  If they are the same firmware level then there is a good chance that the raid array will be recognised but it might not because we do not know where the update firmware failed and what that failure did to the RAID information on the disks.

Now giftmugs, since you said earlier that you were using one of the arrays as a backup of the other I am assuming that backup was up to date.  If that is the case you can then plug the two disks of that backup array into the slots of the replacement unit corresponding to the ones they were in in the old unit then power up the new unit and see if thy are recognised as a RAID 1 array.  If they are then check that you can read your data.  If you can do that then your problems are over and you can plug in the other two disks and check that they are recognised as a RAID 1 array and you can read your data.

Now this is what to do if the backup RAID array is not recognised.

First of all if you had any data on that array that was not the backup plug on of the disks into a USB/SATA caddy/adapter and copy it off that disk to a safe place as I described before.  Once you have done that plug both disks into their corresponding slots on the replacement unit, power it up and create a RAID 1 array.

Once the array is formatted and ready use on of the remaining pair of disks mounted in the USB/SATA caddy/adapter and copy all the data on it over to the new RAID 1 array.  when the copy is complete verify that the data is readable and what you expected, then copy the extra data if there was any.

Now you have a choice.  You can either put the two original disks in the replacement unit and create the second RAID 1 array and then use it as the backup for the first array you created, or you can plug in one of the original disks and a new one, create an array and copy the data from the original disk you replaced with the new one - this gives you a remote backup of your data should you ever need it.

I hope this makes what you need to do a little more clear but it does require you to get a USB/SATA caddy or adapter that has its own power supply (USB ports generally do not supply enough power for the 3.5" disks).  It also means that you need either the software mentioned in the windows recovery sticky or a bootable Linux CD or USB stick.

If you need more help or further explanations don't hesitate to ask. 
Pages: 1 2 3 [4]