Unbrick/Reflash DNS-320L using uBoot and serial port

3,726 views
Skip to first unread message

medi player

unread,
Apr 2, 2015, 7:38:57 AM4/2/15
to al...@googlegroups.com
Hi,

I bricked a DNS-320L during a firmware upgrade and I am now trying to reflash it with the stock D-Link firmware over uBoot using the serial port.
I followed the steps presented here (link was in the Alt-F FAQ/Forum) and extracted the uKernel and uRamdisk files:
http://dns323.kood.org/howto:reflash_from_windows

However the uBoot on the DNS-320L does not support the loadb k/r command. So it's necessary to "manually" transfer the uKernel and uRamdisk files to the device and burn them to the appropriate flash addresses. I have no idea which addresses to use to not brick the device any further (like overwriting uBoot).

I also found this article about how to install Linux on the dns-320l, but again I don't know exactly what the used addresses mean (start?end?offset?size?).
How can I figure out what addresses to use for the uKernel and uRamdisk?

printenv shows several addresses in the bootcmd, console, loadaddr and standalone variables, but I have no clue what to do with them:

Marvell>> printenv
bootargs=root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none
bootcmd=nand read.e 0xa00000 0x100000 0x300000;nand read.e 0xf00000 0x600000 0x300000;bootm 0xa00000 0xf00000
baudrate=115200
loads_echo=0
rootpath=/srv/ubuntu
netmask=255.255.255.0
run_diag=yes
console=console=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x7f00000@0x100000(root)
MALLOC_len=1
ethprime=egiga0
bootargs_root=root=/dev/nfs rw
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
ethaddr=00:50:43:00:02:02
ethmtu=1500
mvPhoneConfig=mv_phone_config=dev[0]:fxs,dev[1]:fxo
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
yuk_ethaddr=00:00:00:EE:51:81
nandEcc=1bit
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
image_multi=yes
ethact=egiga0
ipaddr=192.168.0-2
serverip=192.168.0.1
filesize=2981d94
fileaddr=2000000
stdin=serial
stdout=serial
stderr=serial
mainlineLinux=no
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
bootdelay=1
disaMvPnp=no
enaAutoRecovery=yes
pcieTune=no

Environment size: 1313/131068 bytes


I have never done this before and any help would be greatly appreciated. Thanks!

João Cardoso

unread,
Apr 2, 2015, 12:07:37 PM4/2/15
to al...@googlegroups.com


On Thursday, April 2, 2015 at 12:38:57 PM UTC+1, medi player wrote:
Hi,

I bricked a DNS-320L during a firmware upgrade and I am now trying to reflash it with the stock D-Link firmware over uBoot using the serial port.
I followed the steps presented here (link was in the Alt-F FAQ/Forum) and extracted the uKernel and uRamdisk files:
http://dns323.kood.org/howto:reflash_from_windows

However the uBoot on the DNS-320L does not support the loadb k/r command. So it's necessary to "manually" transfer the uKernel and uRamdisk files to the device and burn them to the appropriate flash addresses. I have no idea which addresses to use to not brick the device any further (like overwriting uBoot).

From u-boot you can use a usb pen, see https://groups.google.com/d/msg/alt-f/vbDtHa8cjpU/PGM-rpO4GU4J and following.

I recommend to not flash from u-boot, but to load a kernel and rootfs into memory (from either a USB pen or tftp server) using u-boot, then booting the loaded kernel and rootfs and then flash from the booted system using its webUI.
I have never flashed a 320/320L/325 from u-boot.

Flash from u-boot is of course possible, follow/ask the site where you found the instructions. But be aware that not everyone wants to preserve/use the D-Link flash partition scheme. See also http://jamie.lentin.co.uk/devices/dlink-dns325.

Remember that each device is different from other. You can't take a procedure or address from a 325 procedure and use it on the 320 or 320L. U-boot and fw is customized for a *particular* board/revision!

If you have any issue with the webUI you can also flash from the command line, there is a topic that address that, https://groups.google.com/d/msg/alt-f/8i2JoItwuFs/sqfrGwtlUswJ
The 320-revB is identical to the 320L-revA, and the procedure to flash from the command line is similar to the 325, after making the necessary (marked red) adaptations.

All the above assumes that you booting Alt-F.
Alt-F (and the D-Link fw) uses another component besides the kernel and rootfs that u-boot handles. For Alt-F that extra fw component contains non-essential software that shouldn't be needed for simple operation. Alt-F RC4.1 when booted from memory through tftp can load that extra component at boot time.

I use the following on 320L-revA from u-boot, after setting up a tftp server on a computer with a 192.168.1.1 IP:

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-A1A2A3
tftp 0xf00000 urootfs-dns325; bootm 0xa00000 0xf00000

The tftp server serves the uImage-DNS-320L-rev-A1A2A3, urootfs-dns325 and the rootfs.arm.sqimage.xz (the extra fw component) files. The files are obtained through the dns323-fw command.



 

I also found this article about how to install Linux on the dns-320l, but again I don't know exactly what the used addresses mean (start?end?offset?size?).
How can I figure out what addresses to use for the uKernel and uRamdisk?

The key is on the 'bootcmd' u-boot variable (quoted from your post):

bootcmd=nand read.e 0xa00000 0x100000 0x300000;nand read.e 0xf00000 0x600000 0x300000;bootm 0xa00000 0xf00000

the 'bootm 0xa00000 0xf00000' command starts the kernel found in memory at 0xa00000 with a rootfs found at 0xf00000
The kernel was read from nand and copied to memory using the command 'nand read.e 0xa00000 0x100000 0x300000'
while the rootfs was read/write using nand 'read.e 0xf00000 0x600000 0x300000'
From that you can infer where in the nand they are located.
Reply all
Reply to author
Forward
0 new messages