I think I bricked my 320L

[Stephen Ban]

I have a DNS-320L Rev. A which was running the latest D-Link firmware (1.06). I then used the D-Link web interface to flash the Alt-F firmware 0.1RC5-DNS320L-RevAx file. It finished the process, and rebooted itself.

However, now all I get is the fast flashing power light. What did I do wrong?

I've already ordered a USB-Serial adapter in case it comes to that.

Thanks!

[Norbert Horváth]

My friend has a DNS-320L, which has this flashing power led thing. It started by failing to boot a few times, then it got more frequent, in the end he had to reboot (power cycle) many times before it booted and now it does not boot anymore. I soldered a serial head and it does not send a single character... I searched in Google and the net is full of this error with DNS-320Ls. It might be some kind of hardware failure, somebody suggested that the capacitors may fail after some time (I may try to replace them but I have very little experience in this). My friend and the majority on the net used only factory firmware, I do not think it has anything to do with Alt-F, the booting should continue at least a little bit further unless the firmware flashing failed at some critical block. If you can get a marvell u-boot prompt (shell) via the serial cable, you have many options to try, this thing can even boot the kernel from a USB drive with the root filesystem also on usb...

[Stephen Ban]

I’m pretty sure it’s not a hardware failure. It was 100% reliable right up until the point where I flashed it.

 

I guess I’ll have to wait until I get the serial cable to post more info.

 

In the meantime, what’s the story with the firmware splitting utility that people have referred to in previous posts? I can’t seem to find it anywhere. Do I still need it if I’m going to reflash back to the original D-Link firmware?

[Norbert Horváth]

The firmware splitting utility can be installed as a Debian package for x86, its name is dns323-firmware-tools.
If you get a Marvell cmdline, I think you should try booting an Alt-F from network or USB (you will need the splitting util for this) and if it works and you can reach its web config, you can still decide what to flash. I did not try flashing from u-boot command line directly, but I think that is also possible.

[João Cardoso]

On Monday, 19 September 2016 21:09:10 UTC+1, Norbert Horváth wrote:

The firmware splitting utility can be installed as a Debian package for x86, its name is dns323-firmware-tools.

Alt-F has its own version C, dns323-fw, that exists on every box with Alt-F installed or can be compiled for any linux distro.

Its source code can be found at https://sourceforge.net/p/alt-f/code/HEAD/tree/trunk/alt-f/package/alt-f-utils/alt-f-utils-0.1.9/dns323-fw.c and I have posted a static binary in this forum, search for 'dns323-fw'. Despite its name it works with all Alt-F supported D-Link firmware file formats.

 

If you get a Marvell cmdline, I think you should try booting an Alt-F from network or USB (you will need the splitting util for this) and if it works and you can reach its web config, you can still decide what to flash. I did not try flashing from u-boot command line directly, but I think that is also possible.

I also advise on loading into memory and running it from within the boot loader (u-boot), instead of trying to flash it in u-boot. In any case you need to split either Alt-F or D-Link firmware files first.

I use the following u-boot commands on my DNS-320L after setting up a tftpserver on my linux box (192.168.1.1)

setenv bootargs console=ttyS0,115200 root=/dev/ram0 init=/init tftpargs=192.168.1.100:192.168.1.1

setenv ipaddr 192.168.1.100

setenv serverip 192.168.1.1

tftp 0xa00000 uImage-DNS-320L-rev-Ax

tftp 0xf00000 urootfs-dns325

bootm 0xa00000 0xf00000

You can also use 'fatload' to load the splited firmware component files from a USB stick, search the forum for 'fatload'

 

I’m pretty sure it’s not a hardware failure. It was 100% reliable right up until the point where I flashed it.

There are some other reports of incorrect flashing, only the linux kernel is flashed, the root filesystem is not.

A log of Alt-F booting with the above commands:

TFTP from server 192.168.1.1; our IP address is 192.168.1.100

Filename 'uImage-DNS-320L-rev-Ax'.

Load address: 0xa00000

Loading: #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         ##################################

done

Bytes transferred = 1834856 (1bff68 hex)

Using egiga0 device

TFTP from server 192.168.1.1; our IP address is 192.168.1.100

Filename 'urootfs-dns325'.

Load address: 0xf00000

Loading: #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         ########

done

Bytes transferred = 3031104 (2e4040 hex)

## Booting image at 00a00000 ...

   Image Name:   Alt-F-0.1RC5, kernel 3.18.28

   Created:      2016-06-25  14:30:55 UTC

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    1834792 Bytes =  1.7 MB

   Load Address: 00008000

   Entry Point:  00008000

   Verifying Checksum ... OK

OK

## Loading Ramdisk Image at 00f00000 ...

   Image Name:   Alt-F-0.1RC5, initrd

   Created:      2016-06-25  14:30:51 UTC

   Image Type:   ARM Linux RAMDisk Image (uncompressed)

   Data Size:    3031040 Bytes =  2.9 MB

   Load Address: 00800000

   Entry Point:  00800000

   Verifying Checksum ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Booting Linux on physical CPU 0x0

Linux version 3.18.28 (jcard@silver) (gcc version 4.3.3 (GCC) ) #1 Fri Jun 17 14:44:39 WEST 2016

CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f

CPU: VIVT data cache, VIVT instruction cache

Machine model: D-Link DNS-320L-rev-Ax NAS

... 

[Norbert Horváth]

Just for the record: I have this 320L with the fast blinking LED and nothing on serial output. Somebody adviced replacing the capacitors, I did it and nothing changed (did not get worse either albeit it is very ugly now). In the process I watched the blinking quite much and the blinking skips a fraction of second frequently like starting over again. I think it is stuck in some low level bootloop, even before u-boot (as it does not write anything on serial), maybe something critical, like the RAM or the NAND chip does not answer. Google finds many users with the same problem (320L), shops replace those under warranty, the others got thrown away (and user never buys D-Link again)...

[João Cardoso]

On Friday, 7 October 2016 19:44:41 UTC+1, Norbert Horváth wrote:

Just for the record: I have this 320L with the fast blinking LED and nothing on serial output.

Are you sure that you haven't exchange the transmit and receive wires? Its's normal to get confused, as you "never" know if tx/rx refers to computer or box (DCE/DTE equipment in RC-232-C terminology, which is pretty confusing in that respect).

Somebody adviced replacing the capacitors, I did it

Wow! I wouldn't  dare, expect as a last resort desperation -- and I did a lot of electronic soldering in my old days :-)

and nothing changed (did not get worse either albeit it is very ugly now). In the process I watched the blinking quite much and the blinking skips a fraction of second frequently like starting over again. I think it is stuck in some low level bootloop,

SoCs, besides the CPU and peripherals controllers (flash, RAM, network, etc) contains an EPROM whose code is  executed at first to run the boot loader itself; SoCs can boot from a variety of devices other than the NAND flash.

So, it is possible that any of the these peripherals (NAND flash controller, or the SoC EPROM itself) are damaged.

But there is a possible counter-argument: the flashing led! is it a feature of the SOC itself, that needs no peripheral working to flash, or is it u-boot that sets it to blink? If the second hypothesis is true, than u-boot is running.

And I suspect that the second hypothesis holds, because the power led is controlled (also? only?) by a second small micro-controller existent in the newer D-Link boxes (starting with the DNS-320) that also controls the fan/temperature/poweroff/etc. But of course, it's possible that the micro-controller at power-up will start flashing the led until instructed by user-programs to stop doing it.

Under Alt-F that micro-controller is handled by the dns320l-daemon (DNS-320-rev-B/320L/327L) or the dns320-temp.sh script (DNS-320-rev-A); the former has even to turn off the power led blinking.

But the 320L is indeed a cheep box. My box is plagued by ECC NAND flash errors, and other users have reported the same symptom, so I will not be surprised if/when my box stops booting any soon.

But it just came to my mind that in some previous linux kernel there was a NOR flash (DNS-321/323)  timing error bug -- it was set to 30 nano-seconds or similar, and some boxes had flash chips that only worked at 35 nano-seconds. Just a reminder -- can it be that some NAND chips have timing issues? Can that be controlled by the linux kernel or by u-boot? Don't know.

I'm sorry for all the previous technicality, is it as understandable as legalese layer talk? :-)