Failed to upgrade RC3 to FC4 on DNS-323 C1

[Jesus Carreras]

 Hi,
first, my appreciation for all this knowledge and value provided to this tiny linux box and their users.

 After some months enjoying ALT-F RC3, I tried a flash to RC4 using web UI on my DNS-323 box.

 Something was not ok, something I missed or I did wrong; the box kept power blue Led flashing slow and permanently, for about an hour, and I powered it off.  When powered on again, always started blinking quick for seconds, then at slow rate.

 I tried the reset button: once for 15 seconds, other 25, and no result.

 After this, I read in the forums, and learn about the serial cable and uBoot. Got it working, see a sample log attached.
 Note  got message:

... ... ...
RAMDISK: squashfs filesystem found at block 0
RAMDISK: Loading 6233KiB [1 disk] into ram disk... done.
SQUASHFS error: Filesystem uses "lzma" compression. This is not supported
List of all partitions:
1f00              64 mtdblock0  (driver?)
1f01              64 mtdblock1  (driver?)
1f02            1536 mtdblock2  (driver?)
1f03            6336 mtdblock3  (driver?)
1f04             192 mtdblock4  (driver?)
0800      1465138584 sda  driver: sd
  0801          530113 sda1 00000000-01
  0802      1073744437 sda2 00000000-02
  0803       390347370 sda3 00000000-03
  0804          514080 sda4 00000000-04
0810      1465138584 sdb  driver: sd
  0811          530113 sdb1 00000000-01
  0812      1073744437 sdb2 00000000-02
  0813       390347370 sdb3 00000000-03
  0814          514080 sdb4 00000000-04
No filesystem could mount root, tried:  ext3 ext2 ext4 squashfs minix vfat msdos
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

I removed disks for backing up my data.

 The same "Kernel panic" message appeared also when I try booting without disks.

 As you can see in the log attached, the kernel checksum is OK (note RC4), also the Ramdisk checksum (note RC3).

 Then I tried different flashing of RC3 Kernel and Ramdisk from firmware, using splitdns323fw utility, serial cable and kermit. Also tried "loadb" of RC4, vendor 1.07 and older kernels.

 All my "loadb" flashing attempts fail the same way: it seems I try to send a cero size kernel/ramdisk that is not properly written to flash. I have not even the chance to issue command "send </home/user/myRC3kernelfile>. No matter the file name of kernel, no matter the path I run kermit. The same on windows with Teraterm.

Marvell>> loadb r
## Ready for binary (kermit) download to 0x00100000 at 115200 bps...
## Total Size      = 0x00000000 = 0 Bytes
## Start Addr      = 0x00100000
Un-Protect Flash Bank # 1
Erase Ramdisk from 0xff9a0000 to 0xfff7ffff Can't erase unknown flash type - aborted
Erased 1 sectors
Can't erase unknown flash type - aborted
Erased 1 sectors
Can't erase unknown flash type - aborted
Erased 1 sectors

 See a flashing log attached as sample with details.

 Most of the references I used to learn what I tried here were related to B1 Hardware; I have C1.

  Is there anything I can do to recover from this? Shall I consider my box bricked?

 Any advice is highly appreciated.


 Kind Regards / Jesus

 

[João Cardoso]

On Tuesday, September 9, 2014 11:34:28 PM UTC+1, Jesus Carreras wrote:

 Hi,
first, my appreciation for all this knowledge and value provided to this tiny linux box and their users.

 After some months enjoying ALT-F RC3, I tried a flash to RC4 using web UI on my DNS-323 box.

 Something was not ok,

Did the flashing succeeded without errors? Both for the kernel and the rootfs? Namely the verify step?

Because, as you noticed, it looks like the kernel was flashed and boots OK, but not the rootfs -- u-boot shows the rootfs header as being the Alt-F-RC3 rootfs, and latter on when the kernel boots and tries to mount and use the rootfs it complains that it is lzma compressed. RC3 was lzma compressed, RC4 is xz compressed, and for the sake of flash space savings the RC4 kernel don't support lzma.

So, for some reason, the rootfs was not successfully flashed and the box still has the RC3 rootfs intact -- as its checksum, as reported by u-boot, is OK.

From the u-boot flashing, I find the "Can't erase unknown flash type" suspicious -- is the flash memory damaged? It's odd that only the rootfs "partition" is damaged...

I remember reading at http://forum.dsmg600.info/viewtopic.php?id=5460  that the 323-rev-C1 u-boot has some severe limitations.

What I would try:

1-as the RC3 rootfs looks OK, I would extract the RC3 kernel and would try to 'loadm' it.

Even if the flash fails, it looks like all 'loadb' commands starts by loading the downloaded file in memory at address 0x00100000 and then depending on the 'loadb' argument, try to flash it to either the kernel or rootfs flash partition.

So, assuming that the kernel downloading to 0x00100000 succeeds, I would 'bootm 00100000 FF9A0000'.

If it works, you would be back to RC3, and you can install the mtd-utils Alt-F package and see if you can flash it using its commands.

Some background:

The default is to 'bootm FF820000 FF9A0000', which are the kernel and rootfs addresses from the flash:

# cat /proc/mtd 

dev:    size   erasesize  name

mtd0: 00010000 00002000 "MTD1"

mtd1: 00010000 00010000 "MTD2"

mtd2: 00180000 00010000 "Linux Kernel"

mtd3: 00630000 00010000 "File System"

mtd4: 00030000 00010000 "u-boot"

As the flash memory is at address ff800000 (u-boot reports  [8192kB@ff800000] Flash:  8 MB), then the kernel address is at ff800000 +  00010000 +  00010000 = ff820000, and the rootfs (File System) is at ff800000 +  00010000 +  00010000 +  00180000 = ff9a0000.

end of background

2-explore the 'loadb' command to see if it accepts other arguments, namely loading address (you already did that, not sure if that's OK)

.

3-try the 'erase' command -- but be sure that it allows erasing only a region of the flash, DON'T erase/touch the u-boot "partition" in any way -- now you already know what its flash address is: ff800000 +  00010000 +  00010000 +  00180000 + 00630000

4-try to flash an alternative u-boot -- this is *very* dangerous, and I don't know if it works or the info here is accurate: http://dns323.kood.org/howto:uboot

 

something I missed or I did wrong; the box kept power blue Led flashing slow and permanently, for about an hour, and I powered it off.  When powered on again, always started blinking quick for seconds, then at slow rate.

Yes, that is the normal boot sequence: blink fast while in u-boot, blink slow what the kernel start executing, 

 I tried the reset button: once for 15 seconds, other 25, and no result.

Alt-F has not booted

looks like flashing fails -- probably defective flash memory. Flash memory is very susceptible and have a limited number of write cycles. With NOR flash chips, the ones used in the 323, a single defective bit turns the whole chip useless.

 All my "loadb" flashing attempts fail the same way: it seems I try to send a cero size kernel/ramdisk that is not properly written to flash. I have not even the chance to issue command "send </home/user/myRC3kernelfile>.

How is that? I notice the wrong size, but I though it was a u-boot display bug. If you can't actually send a file, there's no hope. At 115200 bps, a 1MB file should take some 70 seconds to download, and kermit would print a series of dots while the uploading occurs.

 

No matter the file name of kernel, no matter the path I run kermit. The same on windows with Teraterm.

Marvell>> loadb r
## Ready for binary (kermit) download to 0x00100000 at 115200 bps...
## Total Size      = 0x00000000 = 0 Bytes
## Start Addr      = 0x00100000
Un-Protect Flash Bank # 1
Erase Ramdisk from 0xff9a0000 to 0xfff7ffff Can't erase unknown flash type - aborted
Erased 1 sectors
Can't erase unknown flash type - aborted
Erased 1 sectors
Can't erase unknown flash type - aborted
Erased 1 sectors

 See a flashing log attached as sample with details.

 Most of the references I used to learn what I tried here were related to B1 Hardware; I have C1.

see  http://forum.dsmg600.info/viewtopic.php?id=5460

  Is there anything I can do to recover from this? Shall I consider my box bricked?

 Any advice is highly appreciated.


 Kind Regards / Jesus

Luck

[Jesus Carreras]

 Hi,
thanks for the quick response, with clarified addresses, references, and advices.

 I tried options 1, 2 and 3 with no success. If I cannot loadb neither erase on flash. I have not tried to touch uBoot area.

 I have not explored option 4 yet; I need some time to learn how to get a uBoot image.

 I think the flash is not usable, as it is able to read only, but not make changes from my loadb or erase commands.

  Kind regards,
 /Jesus
 

[João Cardoso]

On Thursday, September 11, 2014 11:42:04 PM UTC+1, Jesus Carreras wrote:

 Hi,
thanks for the quick response, with clarified addresses, references, and advices.

 I tried options 1, 2 and 3 with no success.

-Have you tried the procedure described in the second post of this thread? It applies to the rev-C1 boards, and the poster seems to have success with it.

-Also, have you clarified if you can actually transfer (send) files to the box? As I told, sending a kernel should take some 90 seconds -- does it? For completion, my kermit .kermrc contains:

set LINE /dev/xxx
set speed 115200
set serial 8N1
set flow-control none
set carrier-watch off
set reliable
fast
set prefixing all
set file type bin
set rec pack 4096
set send pack 4096
set window 5
connect

When you try '1', does the kernel starts executing? Does it stops with the same panic error?

Including logs, as you did in the first post, can help, as some details are not apparent for the untrained eye

 

If I cannot loadb neither erase on flash. I have not tried to touch uBoot area.

 I have not explored option 4 yet; I need some time to learn how to get a uBoot image.

Before doing that you must be sure that you can transfer files from the computer to the box using u-boot, and that you can execute them.

The '1' option above does all that, loading a kernel at address 0x100000 and executing it -- if that fails, i.e., the kernel does not starts executing, then you can't either download and execute a new u-boot.

Notice that the procedure described in the '4' link is to start a new u-boot, not to flash one -- after starting and executing it, you can then try to flash it or a new kernel and rootfs.

 I think the flash is not usable,

I'm not so certain about that. The symptoms are not clear-cut. You could flash and can run the new RC4 kernel, but you couldn't flash a new rootfs.

A flash chip has no real "partitions", the mtdx "partitions" are just a convenience for the user, they are just a region of the flash memory with a start address and a length -- there is no partition table in the flash chip.

[Jesus Carreras]

 Hi,
now I discovered I was using kermit transfer the wrong way. Escape sequence "Ctrl-\-c" does not work with my spanish setup. I went back to my PC with Teraterm, this time avoiding the "Ctrl-\-c" and using a menu for kermit mode file tranfer.  So no problems to loadb files to the box now.

El viernes, 12 de septiembre de 2014 17:42:08 UTC+2, João Cardoso escribió:

On Thursday, September 11, 2014 11:42:04 PM UTC+1, Jesus Carreras wrote:

 Hi,
thanks for the quick response, with clarified addresses, references, and advices.

 I tried options 1, 2 and 3 with no success.

-Have you tried the procedure described in the second post of this thread? It applies to the rev-C1 boards, and the poster seems to have success with it.

 Yes, option '1' worked OK, as in the thread , so I could run RC3 Kernel in my box. The binary transfer lasted about 5 mins. at 4KB/sec.

-Also, have you clarified if you can actually transfer (send) files to the box? As I told, sending a kernel should take some 90 seconds -- does it? For completion, my kermit .kermrc contains:

set LINE /dev/xxx
set speed 115200
set serial 8N1
set flow-control none
set carrier-watch off
set reliable
fast
set prefixing all
set file type bin
set rec pack 4096
set send pack 4096
set window 5
connect

When you try '1', does the kernel starts executing? Does it stops with the same panic error?

Including logs, as you did in the first post, can help, as some details are not apparent for the untrained eye

Marvell>> loadb k

## Ready for binary (kermit) download to 0x00100000 at 115200 bps...

## Total Size      = 0x00151adc = 1383132 Bytes

## Start Addr      = 0x00100000
Un-Protect Flash Bank # 1

Erase Kernel from 0xff820000 to 0xff99ffff Can't erase unknown flash type - aborted
Erased 1 sectors
... ... ...
Kernel Size = 1383132
Copy to Flash... done
Protect Flash Bank # 1
Marvell>> cp 0x00100000 02000000 1383132
Marvell>> bootm 02000000 0xff9a0000
## Booting image at 02000000 ...
   Image Name:   Alt-F-0.1RC3, kernel 2.6.35.14
... ... ...

 
 

 

If I cannot loadb neither erase on flash. I have not tried to touch uBoot area.

 I have not explored option 4 yet; I need some time to learn how to get a uBoot image.

Before doing that you must be sure that you can transfer files from the computer to the box using u-boot, and that you can execute them.

The '1' option above does all that, loading a kernel at address 0x100000 and executing it -- if that fails, i.e., the kernel does not starts executing, then you can't either download and execute a new u-boot.

Notice that the procedure described in the '4' link is to start a new u-boot, not to flash one -- after starting and executing it, you can then try to flash it or a new kernel and rootfs.

 I think the flash is not usable,

I'm not so certain about that. The symptoms are not clear-cut. You could flash and can run the new RC4 kernel, but you couldn't flash a new rootfs.

A flash chip has no real "partitions", the mtdx "partitions" are just a convenience for the user, they are just a region of the flash memory with a start address and a length -- there is no partition table in the flash chip.

 

as it is able to read only, but not make changes from my loadb or erase commands.

  Kind regards,
 /Jesus

 Now I have my DNS-323 rev C, in good shape, with RC3, running in RAM, where I have made some config  changes.

 As you reflected for '1', I just had left to replace the RC4 kernel still in flash, with the mtd_utils. So installed them and proceeded:

/mnt/md127/DOCS/FLASH/RC3 # mtd_debug info /dev/mtd2
mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_NORFLASH
mtd.size = 1572864 (1M)
mtd.erasesize = 65536 (64K)
mtd.writesize = 1
mtd.oobsize = 0
regions = 0
 
/mnt/md127/DOCS/FLASH/RC3 # mtd_debug -h
usage: mtd_debug info <device>
       mtd_debug read <device> <offset> <len> <dest-filename>
       mtd_debug write <device> <offset> <len> <source-filename>
       mtd_debug erase <device> <offset> <len>
/mnt/md127/DOCS/FLASH/RC3 # mtd_debug erase /dev/mtd2 0x0 1572864
Erased 1572864 bytes from address 0x00000000 in flash
/mnt/md127/DOCS/FLASH/RC3 # mtd_debug write /dev/mtd2 0x0 1383132 uK
ernel
Copied 1383132 bytes from uKernel to address 0x00000000 in flash
/mnt/md127/DOCS/FLASH/RC3 # mtd_debug info
usage: mtd_debug info <device>
       mtd_debug read <device> <offset> <len> <dest-filename>
       mtd_debug write <device> <offset> <len> <source-filename>
       mtd_debug erase <device> <offset> <len>
/mnt/md127/DOCS/FLASH/RC3 # mtd_debug info /dev/mtd2
mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_NORFLASH
mtd.size = 1572864 (1M)
mtd.erasesize = 65536 (64K)
mtd.writesize = 1
mtd.oobsize = 0
regions = 0
 
/mnt/md127/DOCS/FLASH/RC3 #

 Then I rebooted, and the box started RC3, like it was before the upgrade.

 I think I am ready to test and try again the upgrade RC3 to RC4. This box deserves the latest and greatest available.
 
 I will pay attention to the details this time: steps, available RAM, etc.

 Thank you so much for providing me this experience.
 I will post more input as I try again this change.

KR/Jesus


 

[João Cardoso]

On Sunday, September 14, 2014 4:33:08 PM UTC+1, Jesus Carreras wrote:

 Hi,
now I discovered I was using kermit transfer the wrong way. Escape sequence "Ctrl-\-c" does not work with my spanish setup. I went back to my PC with Teraterm, this time avoiding the "Ctrl-\-c" and using a menu for kermit mode file tranfer.  So no problems to loadb files to the box now.

El viernes, 12 de septiembre de 2014 17:42:08 UTC+2, João Cardoso escribió:

On Thursday, September 11, 2014 11:42:04 PM UTC+1, Jesus Carreras wrote:

 Hi,
thanks for the quick response, with clarified addresses, references, and advices.

 I tried options 1, 2 and 3 with no success.

-Have you tried the procedure described in the second post of this thread? It applies to the rev-C1 boards, and the poster seems to have success with it.

 Yes, option '1' worked OK, as in the thread , so I could run RC3 Kernel in my box. The binary transfer lasted about 5 mins. at 4KB/sec.

Good!

But now it seems that u-boot  succeeds flashing with the 'loadb k' command, although the "Can't erase unknown flash type - aborted" message.

You shouldn't need the to use the 'cp' command -- but this of course can only verified by trying.

For the DNS-321/323, por flash space-saving reasons, Alt-F don't use mtd-utils for flashing, it uses a simple 'cat' command, see /usr/www/cgi-bin/firmware2_proc.cgi, at nor_flash() right at the top.

So as you now have the knowledge and serial adapter, you can try to use Alt-F again to flash RC4. I'm afraid that we will never discovered why it failed the first time.

By the way. 'dns323-fw -h' is the Alt-F command to split/merge a D-Link firmware file. It can be compiled in a linux host, and supports the DNS-321/323/320/320L/325 firmware files. It would be nice if someone would compile it under MS-Win and made a static binary available:  https://code.google.com/p/alt-f/source/browse/trunk/alt-f/package/alt-f-utils/alt-f-utils-0.1.7/dns323-fw.c

This box deserves the latest and greatest available.
 
 I will pay attention to the details this time: steps, available RAM, etc.

 Thank you so much for providing me this experience.
 I will post more input as I try again this change.

Thanks,

João

 

KR/Jesus


 

[Jesus Carreras]

 Hello,

finally, I could upgrade successfully  from RC3 to RC4 using the WebUI. This time the steps took about the time estimated in the WebUI messages. Flashing the kernel: 47 seconds, flashing the rootfs: 191 seconds.

 I need to say I did not reproduce the start conditions I had on my first trial; This time I repartitioned the disks for raid1 only, I removed some applications I was not using, and chose to erase all flashed settings in the upgrade. Then reboot, change some configuration, and ready to go...

 Kind regards,
 
/Jesús

[João Cardoso]

On Thursday, September 18, 2014 10:45:44 PM UTC+1, Jesus Carreras wrote:

 Hello,

finally, I could upgrade successfully  from RC3 to RC4 using the WebUI. This time the steps took about the time estimated in the WebUI messages. Flashing the kernel: 47 seconds, flashing the rootfs: 191 seconds.

Good. We will never know what happened.

 

 I need to say I did not reproduce the start conditions I had on my first trial; This time I repartitioned the disks for raid1 only, I removed some applications I was not using, and chose to erase all flashed settings in the upgrade. Then reboot, change some configuration, and ready to go...

 I just recommend to perform an upgrade right after a fresh reboot, to minimize "troubles"

 

 Kind regards,
 
/Jesús