Support for DNR-326 (hardware identical to DNS-320/DNR-322L) ?

[Jackson Chan]

Hi Joao,

The DNR-326 is also hardware identical (same board) the same as DNS-320/DNR-322L. Can you possibly build a firmware that can be flashed with DNR-326 webui?

I tried to upload your 1.0.1 and the DNR-326 webui wont take it.

I am on firmware 2.0 and it has telnet enabled. Here is the dmesg:

Linux version 2.6.31.8 (jack@swtest6) (gcc version 4.2.1) #14 Thu Aug 15 17:43:14 CST 2013

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

CPU: VIVT data cache, VIVT instruction cache

Machine: Feroceon-KW

Using UBoot passing parameters structure

Memory policy: ECC disabled, Data cache writeback

On node 0 totalpages: 32768

free_area_init_node: node 0, pgdat c0507430, node_mem_map c052e000

  Normal zone: 256 pages used for memmap

  Normal zone: 0 pages reserved

  Normal zone: 32512 pages, LIFO batch:7

Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 32512

Kernel command line: root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none

PID hash table entries: 512 (order: 9, 2048 bytes)

Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

Memory: 128MB = 128MB total

Memory: 115596KB available (4808K code, 321K data, 136K init, 0K highmem)

Hierarchical RCU implementation.

NR_IRQS:128

Console: colour dummy device 80x30

Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

NET: Registered protocol family 16

Feroceon L2: Enabling L2

Feroceon L2: Cache support initialised.

CPU Interface

-------------

SDRAM_CS0 ....base 00000000, size 128MB

SDRAM_CS1 ....disable

SDRAM_CS2 ....disable

SDRAM_CS3 ....disable

PEX0_MEM ....base e0000000, size 128MB

PEX0_IO ....base f2000000, size   1MB

PEX1_MEM ....no such

PEX1_IO ....no such

INTER_REGS ....base f1000000, size   1MB

NFLASH_CS ....base fa000000, size   2MB

SPI_CS ....base f4000000, size  16MB

BOOT_ROM_CS ....no such

DEV_BOOTCS ....no such

CRYPT_ENG ....base f0000000, size   2MB

  Marvell Development Board (LSP Version KW_LSP_5.1.3_patch29)-- DB-88F6281A-BP  Soc: 88F6281 A1 LE

 Detected Tclk 166666667 and SysClk 250000000

MV Buttons Device Load

Marvell USB EHCI Host controller #0: c403e740

PEX0 interface detected no Link.

PCI: bus0: Fast back to back transfers enabled

mvPexLocalBusNumSet: ERR. Invalid PEX interface 1

bio: create slab <bio-0> at 0

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

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

NET: Registered protocol family 1

Trying to unpack rootfs image as initramfs...

rootfs image is not initramfs (no cpio magic); looks like an initrd

Freeing initrd memory: 1724K

rtc mv_rtc: rtc core: registered kw-rtc as rtc0

RTC registered

cpufreq: Init kirkwood cpufreq driver

cpufreq: High frequency: 1000000KHz - Low frequency: 250000KHz

cpufreq: Setting CPU Frequency to 1000000 KHz

cpufreq: Setting PowerSaveState to off

XOR registered 4 channels

XOR 2nd invalidate WA enabled

cesadev_init(c000edc0)

mvCesaInit: sessions=640, queue=64, pSram=f0000000

MV Buttons Driver Load

VFS: Disk quotas dquot_6.5.2

Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

squashfs: version 4.0 (2009/01/31) Phillip Lougher

Installing knfsd (copyright (C) 1996 ok...@monad.swb.de).

JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.

fuse init (API version 7.12)

msgmni has been set to 229

alg: No test for cipher_null (cipher_null-generic)

alg: No test for ecb(cipher_null) (ecb-cipher_null)

alg: No test for digest_null (digest_null-generic)

alg: No test for compress_null (compress_null-generic)

alg: No test for lzma (lzma-generic)

alg: No test for stdrng (krng)

alg: No test for hmac(digest_null) (hmac(digest_null-generic))

Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)

io scheduler noop registered

io scheduler anticipatory registered (default)

Initializing ths8200_init

Initializing dove_adi9889_init

Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A

console [ttyS0] enabled

serial8250.1: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A

brd: module loaded

loop: module loaded

Integrated Sata device found

IRQ 21/mvSata: IRQF_DISABLED is not guaranteed on shared IRQs

scsi0 : Marvell SCSI to SATA adapter

scsi1 : Marvell SCSI to SATA adapter

scsi 0:0:0:0: Direct-Access     Hitachi  HUS724030ALE641  MJ8O PQ: 0 ANSI: 5

scsi 1:0:0:0: Direct-Access     Hitachi  HUS724030ALE641  MJ8O PQ: 0 ANSI: 5

scsi 0:0:0:0: Attached scsi generic sg0 type 0

scsi 1:0:0:0: Attached scsi generic sg1 type 0

Loading Marvell Ethernet Driver:

  o Cached descriptors in DRAM

  o DRAM SW cache-coherency

  o 2 Giga ports supported

  o Single RX Queue support - ETH_DEF_RXQ=0

  o Single TX Queue support - ETH_DEF_TXQ=0

  o TCP segmentation offload (TSO) supported

  o Large Receive offload (LRO) supported

  o Receive checksum offload supported

  o Transmit checksum offload supported

  o Network Fast Processing (Routing) supported - (Disabled)

  o Driver ERROR statistics enabled

  o Proc tool API enabled

  o SKB Reuse supported - (Disabled)

  o SKB Recycle supported - (Disabled)

  o Rx descripors: q0=128

  o Tx descripors: q0=532

  o Loading network interface(s):

     o register under mv88fx_eth platform

     o egiga0, ifindex = 2, GbE port = 0

Warning: Giga 1 is Powered Off

mvFpRuleDb (c4658000): 1024 entries, 4096 bytes

Counter=0, opIdx=6, overhead=16

Counter=1, opIdx=2, overhead=0

Counter=2, opIdx=1, overhead=18

Counter=3, opIdx=2, overhead=0

PPP generic driver version 2.4.2

PPP Deflate Compression module registered

PPP BSD Compression module registered

PPP MPPE Compression module registered

NET: Registered protocol family 24

PPPoL2TP kernel driver, V1.0

NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)

Scanning device for bad blocks

Bad eraseblock 149 at 0x0000012a0000

Using static partition definition

Creating 8 MTD partitions on "nand_mtd":

0x000000000000-0x000000100000 : "u-boot"

0x000000100000-0x000000600000 : "uImage"

0x000000600000-0x000000b00000 : "ramdisk"

0x000000b00000-0x000005100000 : "image"

0x000006f00000-0x000007900000 : "mini firmware"

0x000007900000-0x000007e00000 : "config"

0x000007e00000-0x000008000000 : "my-dlink"

0x000005100000-0x000006f00000 : "nuuo package"

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver

ehci_marvell ehci_marvell.70059: Marvell Orion EHCI

ehci_marvell ehci_marvell.70059: new USB bus registered, assigned bus number 1

ehci_marvell ehci_marvell.70059: irq 19, io base 0xf1050100

ehci_marvell ehci_marvell.70059: USB 2.0 started, EHCI 1.00

usb usb1: configuration #1 chosen from 1 choice

hub 1-0:1.0: USB hub found

hub 1-0:1.0: 1 port detected

ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver

uhci_hcd: USB Universal Host Controller Interface driver

mice: PS/2 mouse device common for all mice

i2c /dev entries driver

md: linear personality registered for level -1

md: raid0 personality registered for level 0

md: raid1 personality registered for level 1

device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-d...@redhat.com

cpufreq: Setting CPU Frequency to 1000000 KHz

cpufreq: Setting PowerSaveState to off

usbcore: registered new interface driver usbhid

usbhid: v2.6:USB HID core driver

TCP cubic registered

NET: Registered protocol family 17

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

rtc mv_rtc: setting system clock to 2019-06-11 00:00:59 UTC (1560211259)

md: Waiting for all devices to be available before autodetect

md: If you don't use raid, use raid=noautodetect

md: Autodetecting RAID arrays.

md: Scanned 0 and added 0 devices.

md: autorun ...

md: ... autorun DONE.

RAMDISK: gzip image found at block 0

EXT2-fs warning: maximal mount count reached, running e2fsck is recommended

VFS: Mounted root (ext2 filesystem) on device 1:0.

Freeing init memory: 136K

sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.

sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)

sd 0:0:0:0: [sda] 0-byte physical blocks

sd 0:0:0:0: [sda] Write Protect is off

sd 0:0:0:0: [sda] Mode Sense: 23 00 10 00

sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA

sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.

 sda:

sd 1:0:0:0: [sdb] Sector size 0 reported, assuming 512.

sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)

sd 1:0:0:0: [sdb] 0-byte physical blocks

sd 1:0:0:0: [sdb] Write Protect is off

sd 1:0:0:0: [sdb] Mode Sense: 23 00 10 00

sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA

sd 1:0:0:0: [sdb] Sector size 0 reported, assuming 512.

 sdb: sda1 sda2 sda4

sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.

sd 0:0:0:0: [sda] Attached SCSI disk

 sdb1 sdb2 sdb4

sd 1:0:0:0: [sdb] Sector size 0 reported, assuming 512.

sd 1:0:0:0: [sdb] Attached SCSI disk

kjournald starting.  Commit interval 5 seconds

EXT3 FS on sda4, internal journal

EXT3-fs: mounted filesystem with writeback data mode.

kjournald starting.  Commit interval 5 seconds

EXT3 FS on sdb4, internal journal

EXT3-fs: mounted filesystem with writeback data mode.

egiga0: mac address changed

egiga0: link down

egiga0: started

egiga0: link up, full duplex, speed 1 Gbps

Initializing USB Mass Storage driver...

usbcore: registered new interface driver usb-storage

USB Mass Storage support registered.

kjournald starting.  Commit interval 5 seconds

EXT3 FS on sda2, internal journal

EXT3-fs: mounted filesystem with writeback data mode.

kjournald starting.  Commit interval 5 seconds

EXT3 FS on sdb2, internal journal

EXT3-fs: mounted filesystem with writeback data mode.

md: md0 still in use.

md: bind<sdb1>

md: bind<sda1>

raid1: raid set md0 active with 2 out of 2 mirrors

md0: detected capacity change from 0 to 542769152

 md0: unknown partition table

Adding 530040k swap on /dev/md0.  Priority:-1 extents:1 across:530040k

NTFS driver 2.1.29 [Flags: R/O MODULE].

usbcore: deregistering interface driver usb-storage

[João Cardoso]

On Friday, 8 May 2020 05:58:19 UTC+1, Jackson Chan wrote:

Hi Joao,

The DNR-326 is also hardware identical (same board)

How have you checked that? Do you have good pictures and circuit board eatched labels describing it?

 

the same as DNS-320/DNR-322L. Can you possibly build a firmware that can be flashed with DNR-326 webui?

Yes, it is possible. From the log you sent they seems to be compatible, but if they are not you will brick your box.

Do you have a serial adapter soldered in the box? That is the most secure route to take, booting Alt-F from a USB device without flashing it; if all runs OK than it can be flashed.

I tried to upload your 1.0.1 and the DNR-326 webui wont take it.

I am on firmware 2.0

D-Link has fw 2.7 available. Alt-F has no NVR specific software nor D-Link specific software.

I have downloaded their v2.7 from http://files.dlink.com.au/products/DNR-326/REV_A/Firmware/Firmware_v2.70B06/ and its fw signature says that it is a DNR-322:

product_id=1;

custom_id=8;

model_id=3;

sub_id=1;

NewVersion=1;

signature="DNR-322";

 

while the DNR-322L says:

product_id=1;

custom_id=8;

model_id=2;

sub_id=1;

NewVersion=1;

signature="DNR-322";

 

[Jackson Chan]

On Friday, May 8, 2020 at 11:24:20 PM UTC+8, João Cardoso wrote:

On Friday, 8 May 2020 05:58:19 UTC+1, Jackson Chan wrote:

Hi Joao,

The DNR-326 is also hardware identical (same board)

How have you checked that? Do you have good pictures and circuit board eatched labels describing it?

A number of years ago, I changed the board from DNS-320 into DNR-326 by cross flashing the firmware. I went from DNS-320, into DNR-322L, then finally into DNR-326. However, I no longer remember how I have done it and the instructions as I have lost all info during a computer crash. 

The project was abandoned and forgotten and I have now taken this off from a pile of junk and want to use this as a regular NAS again. 

 

 

the same as DNS-320/DNR-322L. Can you possibly build a firmware that can be flashed with DNR-326 webui?

Yes, it is possible. From the log you sent they seems to be compatible, but if they are not you will brick your box.

Do you have a serial adapter soldered in the box? That is the most secure route to take, booting Alt-F from a USB device without flashing it; if all runs OK than it can be flashed.

I still have the serial adapter soldered on there. I can reconnect this if necessary.

 

I tried to upload your 1.0.1 and the DNR-326 webui wont take it.

I am on firmware 2.0

D-Link has fw 2.7 available. Alt-F has no NVR specific software nor D-Link specific software.

I also tried v2.7 but they disabled the telnet so I revert back to V2.0. 

 

I have downloaded their v2.7 from http://files.dlink.com.au/products/DNR-326/REV_A/Firmware/Firmware_v2.70B06/ and its fw signature says that it is a DNR-322:

product_id=1;

custom_id=8;

model_id=3;

sub_id=1;

NewVersion=1;

signature="DNR-322";

 

while the DNR-322L says:

product_id=1;

custom_id=8;

model_id=2;

sub_id=1;

NewVersion=1;

signature="DNR-322";

 

Does the partition layout the same as DNR-322L? I bet it is and would read the MAC# correctly. 

If you can build me a firmware I can test it out. I am still fairly comfortable in playing around with hardware.

Or, where is the hex offset in the firmware where it set the model_id? maybe the easiest way is to hex the model id and I can try to flash it. I dont know how the flash routine check for compatible images but I suspect the firmware can be hex edited to get around it? 

[João Cardoso]

Yes, they are identical

 

I bet it is and would read the MAC# correctly. 

 

I believe so. It uses to be stored in the first 2048 bytes of mtd4, a verbatim string, i.e. aa:bb:cc:dd:ee:ff. Actually at boot time it is extracted by Alt-F using

IFMAC=$(nanddump -ql 2048 /dev/mtd4 | grep -E '..(:..){5}')

Do you have linux experience or a linux computer? I have posted in this forum a linux static binary to split/create a firmware file in D-Link format, it's called 'dns323-fw'. Search for it, it might be post in gz compressed format (I will post again nevertheless, with support for the DNR-322L). With it you can display firmware files characteristics, split an existing fw into its components, merge those components together into a new format.

The signatures are in the first 128 file bytes, and for the 322L/326 I believe that a single byte (the model id) is significative.

If you can build me a firmware I can test it out. I am still fairly comfortable in playing around with hardware.

That will probably take a couple of hours or a whole afternoon, as there are several adjustments to do in the source code (define and use DNR-326 where necessary)

 

Or, where is the hex offset in the firmware where it set the model_id? maybe the easiest way is to hex the model id and I can try to flash it. I dont know how the flash routine check for compatible images but I suspect the firmware can be hex edited to get around it? 

Yes, it should be possible to take a Alt-F-1.0.1 DNR-322L fw and change the single byte model_id.

I have never done that. Of course at the end you will end-up with a box identifying itself as a DNR-322L, and only accepting fw for it. I think the best is for you to wait a couple of days until I get an empty time slot and create the DNR-326 specific fw.

Yet safer would be to use the serial adapter, break into u-boot and boot from a USB with the fw components splited by dns323-fw.

If you can read C, model_id should be at offset 12x4+12+3) from the file beginning

 typedef struct {

uint32_t kernel_off;

uint32_t kernel_len;

uint32_t initramfs_off;

uint32_t initramfs_len;

uint32_t sqimage_off;

uint32_t sqimage_len;

uint32_t defaults_off;

uint32_t defaults_len;

uint32_t kernel_checksum;

uint32_t initramfs_checksum;

uint32_t sqimage_checksum;

uint32_t defaults_checksum;

uchar magic_num[SIG_LEN]; // SIG_LEN=12

uchar product_id;

uchar custom_id;

uchar model_id;

uchar sub_id;

uchar NewVersion;

uchar reserved[RESERVED128]; //all structure is 128 bytes

uint32_t Next_offset;

} CONTROL_HEADER_128;

Please keep posting your progress

[Jackson Chan]

From the info you gave me, I have changed the model ID here from 02 to 03 and I can confirm that it is working with my converted DNR-326. It pulls the right MAC address which starts with CC:B2:55 and it mean this is address is from DLINK. 

You are right that it is now being recognized as a DNR-322L. I actually want it to be recognized as DNS-320 again(I want to get rid of all the 322/326 stuff that was part of the abandoned projects). Should I just hex edit a Alt-f 1.0 DNS-320 bin to match 02 or 03 model id and repeat this? (But I saw that there were 2 fixes for 1.0 to go to 1.01, maybe something need to be done the other direction?)

[Jackson Chan]

Do I have a faulty sensor or it wasnt read correctly? Or do I just have very hot disk (Hitachi HUS724030ALE641) ? 

The box just shutdown by itself when it was trying to resync. Now I have powered it back on and saw this. Will it poweroff when overheat? Is there a setting somewhere for this?

[Rolf Pedersen]

On 5/9/20 11:17 PM, Jackson Chan wrote:

Do I have a faulty sensor or it wasnt read correctly? The box just shutdown by itself when it was trying to resync. Now I have powered it back on and saw this.

--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/alt-f/8036f8a5-4beb-4015-8478-7bf37e16189b%40googlegroups.com.

failed_sensor.png

I'd guess running rsync caused a temporary rise in the system temperature that exceeded the thresholds set in Services > System > sysctrl > Configure.
This sort of thing has happened to me and I upped the values.  Make sure the airway for cooling ventilation is not blocked.
Rolf

[João Cardoso]

On Sunday, 10 May 2020 03:07:07 UTC+1, Jackson Chan wrote:

From the info you gave me, I have changed the model ID here from 02 to 03 and I can confirm that it is working with my converted DNR-326.

This is something that I miss in one of your posts:

A number of years ago, I changed the board from DNS-320 into DNR-326 by cross flashing the firmware. I went from DNS-320, into DNR-322L, then finally into DNR-326

 

So you don't actually have a DNR-326 box/board, right? You have a DNS-320. Which rev? I guess rev-A1. There are two HW (hardware board) versions, rev-A1 and rev-B1, and their circuit boards are quite different. It happens that the DNS-320L-rev-Ax board is the *same* board as the DNS-320-rev-Bx (apart the amount of memory). They were compared by visual inspection including the matching etched circuit board description.

They are so different that fan/temperature/led/power-button/poweron/poweroff activation, etc, are different. They use the same SOC, and that enables one to run *some* apps designed for the other. But that does not means all apps, and some might be crucial.

In general, you might very likely brick a box by flashing fw that was not designed for it (circuit board).

It pulls the right MAC address which starts with CC:B2:55 and it mean this is address is from DLINK. 

You are right that it is now being recognized as a DNR-322L. I actually want it to be recognized as DNS-320 again(I want to get rid of all the 322/326 stuff that was part of the abandoned projects). Should I just hex edit a Alt-f 1.0 DNS-320 bin to match 02 or 03 model id and repeat this? (But I saw that there were 2 fixes for 1.0 to go to 1.01, maybe something need to be done the other direction?)

That's not so simple.

A DNS-320-rev-A1 fw header contains, as displayed by dns323-fw (you have it now in Alt-F, you don't need a linux PC):

product_id=0;

custom_id=8;

model_id=7;

sub_id=2;

NewVersion=0;

signature="DNS323D1";

For comparison, a DNS-320-rev-B1 fw header contains:

product_id=0; 

custom_id=8;
model_id=c;
sub_id=1;
NewVersion=1;
signature="DNS320B";

The DNR-322L has a different flash partition layout than the DNS-320-revA1. *some* of its fw even contains an additional section intended to update an extra flash partition, as displayed by dns323-fw:

...

 

Next header at 52908524: dir=/mnt/HD_a4/install file=DNR-322L-nuuo_package

Alt-F, and its dns323-fw utility, doesn't handle that section, it only displays that info.

The reason for the 1.0.1 DNR-322L release and fixes was to correct the misinformation that the DNR-322L was identical to the DNS-320. It is not.

When "supporting" a box model, I try to guarantee that any user must have the freedom and ability to flash Alt-F and easily return back to the vendor fw if he wishes to do so.

So, what can you do? Either maintain your box as is now, it's working, or flash from the command line (either from Alt-F or from u-boot) your prefered fw. The dns323-fw program enables you to split supported D-Link compatible fw into its (main) components and rewrap them into a new fw. It is available from within Alt-F, as it is essential for flashing.

There are several topics covering the manual Alt-F flashing procedure (at least for the DNS-323, 325 and 320L)

Luck

[Jackson Chan]

A number of years ago, I changed the board from DNS-320 into DNR-326 by cross flashing the firmware. I went from DNS-320, into DNR-322L, then finally into DNR-326

 

So you don't actually have a DNR-326 box/board, right? You have a DNS-320. Which rev? I guess rev-A1. There are two HW (hardware board) versions, rev-A1 and rev-B1, and their circuit boards are quite different. It happens that the DNS-320L-rev-Ax board is the *same* board as the DNS-320-rev-Bx (apart the amount of memory). They were compared by visual inspection including the matching etched circuit board description.

They are so different that fan/temperature/led/power-button/poweron/poweroff activation, etc, are different. They use the same SOC, and that enables one to run *some* apps designed for the other. But that does not means all apps, and some might be crucial.

In general, you might very likely brick a box by flashing fw that was not designed for it (circuit board).

Correct. I have the DNS-320 rev A1. 

The DNR-326 and DNR-322 have 256mb ram and the DNS-320revA has 128mb ram. The difference between the DNR-326 and DNR-322L is that the DNR-322L is crippled in software that only allow it to connect to dlink ip camera and DNR-326 support others. 

Yes I am aware that the DNR-322L and the DNS-320revA1 have different flash format from my vague memory(as I had converted from DNS-320 flash format into DNR-322L before). I think at some firmware version both might have the same format, but I could be wrong as I just completely forget how/what I did before but it also involved splitting firmware and flashing manually. 

I guess I will have a look but at the moment this is running well with Alt-F and I am pretty happy.

[João Cardoso]

On Monday, 11 May 2020 01:48:16 UTC+1, Jackson Chan wrote:

A number of years ago, I changed the board from DNS-320 into DNR-326 by cross flashing the firmware. I went from DNS-320, into DNR-322L, then finally into DNR-326

 

So you don't actually have a DNR-326 box/board, right? You have a DNS-320. Which rev? I guess rev-A1. There are two HW (hardware board) versions, rev-A1 and rev-B1, and their circuit boards are quite different. It happens that the DNS-320L-rev-Ax board is the *same* board as the DNS-320-rev-Bx (apart the amount of memory). They were compared by visual inspection including the matching etched circuit board description.

They are so different that fan/temperature/led/power-button/poweron/poweroff activation, etc, are different. They use the same SOC, and that enables one to run *some* apps designed for the other. But that does not means all apps, and some might be crucial.

In general, you might very likely brick a box by flashing fw that was not designed for it (circuit board).

Correct. I have the DNS-320 rev A1.

Pitty. I was ready to make a DNR-326 release :-| 

 

The DNR-326 and DNR-322 have 256mb ram and the DNS-320revA has 128mb ram. The difference between the DNR-326 and DNR-322L is that the DNR-322L is crippled in software that only allow it to connect to dlink ip camera and DNR-326 support others. 

Those are user-perceived differences, doesn't mean the boards are identical. The firmware is able to adapt itself to different boards. E.g., the Alt-F fw for the DNS-320/320L/325, DNR-322L on all its HW rev versions, is the same, although the boards are very different.

The fact that you was able to flash and run the fw for the DNR-326 on a DNS-320 board is not very significative.

So, order to have Alt-F for the DNR-326 we have to wait for a user with a real DNR-326 that wants to test Alt-F on it, is willing and able to solder three wires on the board, report any hardware issues and collaborate to solve them. This will take several days.

You boot log was however helpful, thanks.

[Jackson Chan]

Does anyone have old firmware for the DNR-322L that has version below 2.0? 

[João Cardoso]

Which one do you want? Do you have a site so I can upload them?

-rw-r--r--  1 jcard users  61592620 out 18  2013 DLINK_DNR-322_2.00b07.bin
-rw-r--r--  1 jcard users  28998678 jul  3  2013 DLINK_DNR-322L_1.50b03.bin
-rw-r--r--  1 jcard users  59468364 mar  5  2019 DNR-322L_Ax_v2.60b15.bin
-rw-r--r--  1 jcard users  39246198 dez 28  2016 DNR-322L_B1_V3.01.04.bin
-rw-r--r--  1 jcard users  28978965 out 31  2019 DNR-322L_FIRMWARE_1.50_BETA.zip
-rw-r--r--  1 jcard users  61833668 out 31  2019 DNR-322L_FIRMWARE_2.00B07.zip
-rw-r--r--  1 jcard users  19953159 dez  6  2011 DNR322L_FW_V1.10b02
-rw-r--r--  1 jcard users  20288049 out 31  2019 DNR322L_FW_V1.10b02.zip  
-rw-r--r--  1 jcard users  56191568 dez 17  2014 DNR-322L_REVA_FIRMWARE_2.20.B01
-rw-r--r--  1 jcard users  56005241 out 28  2019 DNR-322L_REVA_FIRMWARE_2.20.B01.zip
-rw-r--r--  1 jcard users  58145356 set 28  2015 DNR-322L_REVA_FIRMWARE_2.40.B03.bin
-rw-r--r--  1 jcard users  57917745 nov 19  2018 DNR-322L_REVA_FIRMWARE_2.40.B03.ZIP
-rw-r--r--  1 jcard users  59075776 out 31  2019 DNR-322L_REVA_FIRMWARE_v2.60B15_BETA.zip
-rw-r--r--  1 jcard users  29920324 nov 19  2018 DNR-322L_REVB_FIRMWARE_3.01.04.zip

[Jackson Chan]

On Thursday, May 14, 2020 at 12:02:40 AM UTC+8, João Cardoso wrote:

Which one do you want? Do you have a site so I can upload them?

DNR-322L_FIRMWARE_1.50_BETA.zip and DNR322L_FW_V1.10b02.zip sounds good.

I dont have a site. Can you put them in some googledrive? 

BTW, I have just tried to flash dnr-322L 2.0 original firmware from Alt-f 1.0.1, of course it works and then I went on to flash back Alt-f 1.0 DNS-322L bin and now it said it is DNS-320(as expected as you said in the doc)

It seems like it is still ok here, the mac is still correct and the partition now:

Creating 6 MTD partitions on "orion_nand":

0x000000000000-0x000000100000 : "u-boot"

0x000000100000-0x000000600000 : "uImage"

0x000000600000-0x000000b00000 : "ramdisk"

0x000000b00000-0x000007100000 : "image"

0x000007100000-0x000007b00000 : "mini firmware"

0x000007b00000-0x000008000000 : "config"

which seems like the one in original DNS-320 firmware?

Anything that i should be checking for possible error?

[João Cardoso]

On Wednesday, 13 May 2020 18:08:45 UTC+1, Jackson Chan wrote:

On Thursday, May 14, 2020 at 12:02:40 AM UTC+8, João Cardoso wrote:

Which one do you want? Do you have a site so I can upload them?

DNR-322L_FIRMWARE_1.50_BETA.zip and DNR322L_FW_V1.10b02.zip sounds good.

I dont have a site. Can you put them in some googledrive? 

https://drive.google.com/file/d/1cF4O1QVpop-FvVkBpVA6hwcoPgX8lq-k/view?usp=sharing, https://drive.google.com/file/d/1po_Ql04O9biAbaRVu4LbVAgDxqjFbU-b/view?usp=sharing I will delete them in a couple of hours.

 

I think to remember that initial DNR-322L fw didn't had the 'nuuo_package', and later had a fw extra section (not handled by Alt-F) that creates it, at expenses of the 'image' partition size. On the 320L a 'my-dlink' partition appears at the end (it might contain box-related credentials for the D-Link cloud service). The network MAC is in the initial 2048 bytes of the 'image' partition, and moving/resizing partitions might overwrite it.

[Jackson Chan]

https://drive.google.com/file/d/1cF4O1QVpop-FvVkBpVA6hwcoPgX8lq-k/view?usp=sharing, https://drive.google.com/file/d/1po_Ql04O9biAbaRVu4LbVAgDxqjFbU-b/view?usp=sharing I will delete them in a couple of hours.

Thanks I have downloaded it.

 

 

I think to remember that initial DNR-322L fw didn't had the 'nuuo_package', and later had a fw extra section (not handled by Alt-F) that creates it, at expenses of the 'image' partition size. On the 320L a 'my-dlink' partition appears at the end (it might contain box-related credentials for the D-Link cloud service). The network MAC is in the initial 2048 bytes of the 'image' partition, and moving/resizing partitions might overwrite it.

I remembered in the dnr-322L firmware there is a user space bin (i cannot remember the filename but it was provided by dlink) that can be used to re-write the mac address into the correct place, that's what I did after cross flashing from DNS-320 into DNR-322L before. 

Is marvell-cesa working on the DNS-320 with Alt-f 1.0?

[João Cardoso]

On Thursday, 14 May 2020 05:29:12 UTC+1, Jackson Chan wrote:

https://drive.google.com/file/d/1cF4O1QVpop-FvVkBpVA6hwcoPgX8lq-k/view?usp=sharing, https://drive.google.com/file/d/1po_Ql04O9biAbaRVu4LbVAgDxqjFbU-b/view?usp=sharing I will delete them in a couple of hours.

Thanks I have downloaded it.

Removed 

 

 

I think to remember that initial DNR-322L fw didn't had the 'nuuo_package', and later had a fw extra section (not handled by Alt-F) that creates it, at expenses of the 'image' partition size. On the 320L a 'my-dlink' partition appears at the end (it might contain box-related credentials for the D-Link cloud service). The network MAC is in the initial 2048 bytes of the 'image' partition, and moving/resizing partitions might overwrite it.

I remembered in the dnr-322L firmware there is a user space bin (i cannot remember the filename but it was provided by dlink) that can be used to re-write the mac address into the correct place, that's what I did after cross flashing from DNS-320 into DNR-322L before. 

That's not difficult to do, just use 'nanddump' to dump the initial 2048 bytes of mtd4 (mini-firmware) into a file, then 'sed' it to replace the MAC pattern, 'flash_erase' the first 2048 bytes (hmmm, better use the eraseblock size), and 'nandwrite' the modified copy to mtd4. I had to do it once as I accidentally erased mtd4. At init time, in /etc/init.d/rcS, the MAC is read using:

# MAC is stored in /dev/mtd4, configure eth0

IFMAC=$(nanddump -ql 2048 /dev/mtd4 | grep -E '..(:..){5}')

if test -n "$IFMAC"; then

ifconfig eth0 hw ether $IFMAC

fi

Are you a linux experienced user? With hardware knowledge?

But mtd4 also contains a recovery system, so to preserve it is advisable to have a backup of the whole mtd4. 

Under certain circumstances, the u-boot boot loader loads and runs a kernel and initrd from mtd4. That minimum system presents the user with a simple webUI able to re-flash the box. That happened once to me, but I was not able to successfully load and run that recovery system  directlty from within u-boot. Knowing more about this process could be helpful and an interesting project.

Is marvell-cesa working on the DNS-320 with Alt-f 1.0?

I suppose so, I don't own one myself. It's not working on the DNS-323 (and possibly also not on the DNS-321, which has the same SOC architecture). But openssl is not using it, so no hw accelerated ssh/sshd/hhtps is available; only device mapper is using it (cryptsetup). And  marvell-cesa only supports some "old" ciphers and hashes.

On the other side, 'kexec' is working on the DNS-323/321 and not on other boxes. And I know why (L2 cache not disabled) but I can't fix nor find a fix for it.

[Jackson Chan]

On Friday, May 15, 2020 at 12:18:18 AM UTC+8, João Cardoso wrote:

On Thursday, 14 May 2020 05:29:12 UTC+1, Jackson Chan wrote:

https://drive.google.com/file/d/1cF4O1QVpop-FvVkBpVA6hwcoPgX8lq-k/view?usp=sharing, https://drive.google.com/file/d/1po_Ql04O9biAbaRVu4LbVAgDxqjFbU-b/view?usp=sharing I will delete them in a couple of hours.

Thanks I have downloaded it.

Removed 

 

 

I think to remember that initial DNR-322L fw didn't had the 'nuuo_package', and later had a fw extra section (not handled by Alt-F) that creates it, at expenses of the 'image' partition size. On the 320L a 'my-dlink' partition appears at the end (it might contain box-related credentials for the D-Link cloud service). The network MAC is in the initial 2048 bytes of the 'image' partition, and moving/resizing partitions might overwrite it.

I remembered in the dnr-322L firmware there is a user space bin (i cannot remember the filename but it was provided by dlink) that can be used to re-write the mac address into the correct place, that's what I did after cross flashing from DNS-320 into DNR-322L before. 

That's not difficult to do, just use 'nanddump' to dump the initial 2048 bytes of mtd4 (mini-firmware) into a file, then 'sed' it to replace the MAC pattern, 'flash_erase' the first 2048 bytes (hmmm, better use the eraseblock size), and 'nandwrite' the modified copy to mtd4. I had to do it once as I accidentally erased mtd4. At init time, in /etc/init.d/rcS, the MAC is read using:

# MAC is stored in /dev/mtd4, configure eth0

IFMAC=$(nanddump -ql 2048 /dev/mtd4 | grep -E '..(:..){5}')

if test -n "$IFMAC"; then

ifconfig eth0 hw ether $IFMAC

fi

Are you a linux experienced user? With hardware knowledge?

Yes I am. I can also do micro soldering. I just couldnt remember what i have done years ago and wanted a quick way out. But guess not. 

 

But mtd4 also contains a recovery system, so to preserve it is advisable to have a backup of the whole mtd4. 

Under certain circumstances, the u-boot boot loader loads and runs a kernel and initrd from mtd4. That minimum system presents the user with a simple webUI able to re-flash the box. That happened once to me, but I was not able to successfully load and run that recovery system  directlty from within u-boot. Knowing more about this process could be helpful and an interesting project.

Is marvell-cesa working on the DNS-320 with Alt-f 1.0?

I suppose so, I don't own one myself. It's not working on the DNS-323 (and possibly also not on the DNS-321, which has the same SOC architecture). But openssl is not using it, so no hw accelerated ssh/sshd/hhtps is available; only device mapper is using it (cryptsetup). And  marvell-cesa only supports some "old" ciphers and hashes.

so do we need to recompile openssl to use this or something?  

On the other side, 'kexec' is working on the DNS-323/321 and not on other boxes. And I know why (L2 cache not disabled) but I can't fix nor find a fix for it.

How do I know it is working? I want to play with rclone (https://rclone.org/) and if hardware acceleration is working it will be quite cool.

 

[Rogerio Passos]

I did the installation of the last version to DNR-322L (Alt-F-1.0.1-DNR-322L-rev-Ax.bin) on my DNR-326 A1 and works fine!
I used winhex editor to modify Alt-F bin file, change  model_id to 3 to match the DNR-326 model_id, that as you say before has  signature as DNR-322

I used the original web interface to upload the  modified Alt-F firmware that was acepted and now works fine on my device.

So I think that you can do oficially this modification and include the DNR-326 A1 on supported devices.

many thanks!