DSM-G600, DNS-3xx and NSA-220 Hack Forum

yeah actually I think that's a great idea... But, maybe it would be better if we know how to recover from a bad flash first?! I mean... what if you screw up ? (I'm propably going to!)

Can you make a short summary of the DSM-G600 recovery procedure for those unfamiliar with that platform? :-)

Hi,
The good news is that you can break into the u-boot loader. Type "5784468" without the quotes at the bash prompt


This appears to be by design after looking at the u-boot sorce code.

in u-boot-1_1_1/common/main.c - line 409 is the staement:
   s = getenv ("bootcmd");
line 426 runs the result:
    run_command (s, 0);

line 426 runs because CFG_HUSH_PARSER is undefined in
       include/configs/db88f5181.h:#undef CFG_HUSH_PARSER

The boot command is set to a firmware default because the environment has an invalid CRC
See  common/env_flash.c, function env_init starting at line 252
The environment pointer gets set to 0xff800000
Where are the environment strings ???
include/configs/db88f1181.h:#define  CFG_ENV_IS_IN_FLASH   
#define CFG_ENV_IS_IN_FLASH     1
#define CFG_ENV_SIZE            0x8000  /* Total Size of Environment Sector */
#define CFG_ENV_SECT_SIZE       0x10000
#define CFG_ENV_ADDR            (CFG_FLASH_BASE)   1
#define CFG_FLASH_BASE          BOOTDEV_CS_BASE
board/mv88fxx81/mvSysHwConfig.h:#define BOOTDEV_CS_BASE      0xff800000
include/configs/db88f5181.h:#define CFG_MONITOR_BASE  (CFG_FLASH_BASE + 0x10000)

I added code in tools/envcrc.c and compiled with the ARM toolchain on the DNS-323
to dump the following defines  - so they at least are verified and will help trace the code
CFG_ENV_IS_IN_NVRAM: UNDEFINED
CFG_ENV_IS_IN_EEPROM: UNDEFINED
CFG_ENV_IS_IN_FLASH: 1
CFG_ENV_IS_IN_DATAFLASH: UNDEFINED
CFG_ENV_IS_IN_NOWHERE: UNDEFINED
ENV_IS_EMBEDDED - UNDEFINED
MV_TINY_IMAGE: UNDEFINED
CFG_ENV_ADDR: ff800000
CFG_FLASH_BASE: ff800000
BOOTDEV_CS_BASE: ff800000
CFG_ENV_OFFSET: 0
CFG_ENV_SIZE: 8000
ENV_HEADER_SIZE: 4
ENV_SIZE: 7ffc
CFG_ENV_ADDR_REDUND: UNDEFINED
CFG_ENV_OFFSET_REDUND: UNDEFINED
CFG_ENV_SIZE_REDUND: UNDEFINED
CFG_ENVSECT_SIZE: UNDEFINED
CFG_MONITOR_BASE: ff810000
CFG_MONITOR_LEN: 60000
CONFIG_BOOTCOMMAND: bootm FF820000 FF9A0000
CONFIG_BOOTDELAY: 3



I am looking at the the 10pin port and see if this is a JTAG port. I have a spare  DNS-323 and will really start digging... Well it is See JTAG WIKI documentation for details http://dns323.kood.org/hardware:jtag

Last edited by magore (2007-03-04 11:36:31)

you can expect one. no doubt about that.

or call d-link and say it just stopped working

and ofcose refuse all about using this forum

KRH wrote:

or call d-link and say it just stopped working

and ofcose refuse all about using this forum

yep thats what i do when I hack something and it no longer works

not trying to tell people to commit fraud but maybe Dlink should of made a better product and maybe made it open source so people can do this without the fear of Dlink telling you you voided the warranty with what you did

or get it lightning fast from here:
http://gpl.nas-central.org/D-LINK/

dlink throttles it to about 25 KB/second.

i am also very interested in a firmware builder tool for the dns-323. it would be exactly the tool needed so foonas/foonas-em ( http://foonas.org ) can support the dns-323.

Last edited by mindbender (2008-05-13 15:15:55)

i suppose you mean merge.tar.gz ...... are the firmwares of the dns-323 and the CH3SNAS looking similar or are the completely different?

i just took a look and it really seems as if everything is there for creating a custom firmware. merge-FrodoII.c is the most important file.

main reason why the guy who uploaded the ch3snas fw to the dns323 could not flash back was probably a slightly different handling of the fw through the running OS....probably there was no md5 or something in one firmware.

so.....custom firmwares should be possible then. the opinion that it is not easily possible to move back to the stock firmware is understandable...but what about tftp then? foonas-em is targets exactly that..its a recent kernel + initramfs which can be loaded via tftp and which is an installer (repartitioning hdd if needed, downloading rootfs from the internet (bootstrapping to debian/ubuntu server/ installing gentoo is planned) and untaring on the rootfs partition)....its not just done for foonas....

but that does not help with the tftp problem.....what happens if a dns-323 is booted with a partitionless hdd? does it request kernel/initrd via tftp or does it do nothing?

Last edited by mindbender (2008-05-20 14:37:23)

mindbender wrote:

what happens if a dns-323 is booted with a partitionless hdd? does it request kernel/initrd via tftp or does it do nothing?

The firmware root filesystem is on flash (it seems with disk-based extension since 1.05). It will start as usual, and after selecting an option in the web interface, it'll partition and format the disks.

i think it puts in some hash in that checks what devices it made for.

mindbender wrote:

i ask myself what happens if the flash rootfs is corrupted and does not boot.....maybe it then falls back to tftp requests?

how exactly does the 8 MB flash look like?

what does

Code:

cat /proc/mtd

tell?

are there tools included in the stock dns323 firmware that allow modifying the uboot variables (called maybe "nvram")?

/ # 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"

And no nvram and have not found any uboot variables program.