NSA320 - Completely Stock OS 4.70

Hi there,

I have a completely stock NSA320 and would like to both upgrade the uboot and install debian to USB.

Where do I start? I've read some forum posts here that everything can be done in the stock OS without using the uart connection. Is this true?

If so how?

Otherwise I'll go ahead in install a UART-USB link.

Hope you can help.

conoral11,

> I have a completely stock NSA320 and would like to
> both upgrade the uboot and install debian to USB.
>
> Where do I start? I've read some forum posts here
> that everything can be done in the stock OS
> without using the uart connection. Is this true?
>

True. But serial console connection would be best to have, in case you run into any problem and need to rescue it. And look at the u-boot installation instruction to see that you should try UART booting with kwboot first, if you have serial console.

From stock OS, you can install both U-Boot and Debian rootfs (Debian rootfs on USB drive, if your HDD already have data on it).

U-Boot:
https://forum.doozan.com/read.php?3,12381

Debian:
https://forum.doozan.com/read.php?2,12096

If you decide to install without serial console connected then before you reboot, you could post the log of the entire session here and I'll double check for you..

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

The missing link for me was how to enable the telnet interface, as there wasn't an option in the stock firmware interface to enable it.

Using:

http://NSA320_IP/r41794,/adv,/cgi-bin/remote_help-cgi?type=backdoor

(changing r41794 to what ever your NSA320 puts in the address bar)

Enables the telnet interface, then its just following the instructions in the links above.

Hope that helps.

Good to know you are getting it working.
I have just last weekend (Nov 7&8) flashed my nsa320 over to buster .

The serial console was easy to setup from an extra raspberry pi I had , so didn't need to buy usb-tty adapter.

Hi!
I read you have a stock NSA320, but probably you already flashed it with new U-Boot and Debian.
If you haven't flashed it yet I am very interested in a dump of your nand to restore an NSA320 I have with stock firmware.
I will PM you as well hoping you will read both this thread and PMs.
Thanx, Paolo.

@psychokiller

Download this archive, unzip it to a USB stick.
Power off NSA320, connect the stick to it, power on, wait (you can watch via TTL serial if you have it connected).

https://mega.nz/file/Sz5jDKKJ#gm1NdQBVt9WhkRO4q0Cf6RPJdS7Fp537jkv0a6sRz-0

Got this from deep inside of one of the many official ZyXEL ftp locations, downloaded some years ago, it is a recovery stick.
It will restore the NSA320 to one of the original firmware, and you can then update to the latest available.

Not sure about the MAC address restore (if it writes the correct one....), can't remember, haven't used this tool in >2 years now.

Cheers.



Edited 2 time(s). Last edit at 01/05/2021 06:27AM by vcheche.

Hi there,

I am new on this forum, so if I should not post my issue here, could you tell me where I should post it?

I also would like to upgrade to Debian on my NSA320. But unfortunately I have sort of bricked my NAS in testing all sorts of commands which I thought were only reading, but I must have done something that makes the boot fail.
I had fonz fun plug and entware installed, and I do not exactly know how this was functioning. I assume that entware overruled fonz fun plug. But other than this it was pretty much a stock version 4.7 firmware. Ik have not installed new uboot's or anything. It must have been using the disks as well through a clever kind of of hooking through symbolic links created by the fun_plug.sh hook, but I do not know the details of this process.

I had to reboot the machine recently and it did start to a certain point, because all the led's were on, other than that it appeared dead, the disks did not spin-up and I could not connect to it.

As I am also playing around with arduino I had a pl2303 lying around, so I hooked it up to the serial pins of the NSA320 and used putty to have a look at the boot process.

The thing that looks bad the most is this:

reading NAND page at offset 0x4640000 failed
 10485760 bytes read: ERROR
## Booting image at 02000000 ...
Bad Magic Number

Here is the (complete) output including a few commands somebody will ask me for, so I am anticipating on that:

        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|
 ** MARVELL BOARD: RD-88F6281A LE

U-Boot 1.1.4 (Mar 23 2011 - 16:09:39) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM CS[1] base 0x10000000   size 256MB
DRAM Total size 512MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
//---  stateButtonBit = 3, recovery ---//
Kernel address is 0x4640000.

Streaming disabled
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x4640000, size 0xa00000

reading NAND page at offset 0x4640000 failed
 10485760 bytes read: ERROR
## Booting image at 02000000 ...
Bad Magic Number


NSA320>> version
U-Boot 1.1.4 (Mar 23 2011 - 16:09:39) Marvell version: 3.4.19

NSA320>> sp

Bus: 0 Device: 0 Func: 0 Vendor ID: 11ab Device ID: 6281
-------------------------------------------------------------------
Class: Memory controller
PCI_BAR0 (Mem-64bit) base: 0f1000000    size: 1048576 bytes
PCI_BAR1 (Mem-64bit) base: 000000000            size: 536870912 bytes

NSA320>> sg
PHY 0 :
---------
Auto negotiation: Enabled
Speed: 1000 Mbps
Duplex: Half
Link: down

PHY 1 :
---------
Auto negotiation: Enabled
Speed: Uknown
Duplex: Full
Link: up

NSA320>> dclk
TCLK 200Mhz, SYSCLK 400Mhz (UART baudrate 115200)

NSA320>> printinfo
kernel_addr_1=0xc80000
kernel_mtd_1=5
sysimg_mtd_1=6
kernel_addr_2=0x4640000
kernel_mtd_2=7
sysimg_mtd_2=8
fwversion_1=V4.70(AFO.1)
revision_1=41794
modelid_1=DD01
core_checksum_1=678f3d0f5000c5e00235856a6c186057
zld_checksum_1=15b8a3bfb65e6ad60f55fc7f23e76171
romfile_checksum_1=98E5
img_checksum_1=010c65c574d9a45f2a09f451a92c1611
fwversion_2=V4.70(AFO.3)
revision_2=49435
modelid_2=DD01
core_checksum_2=81e0d1021bdce8c0cca99e237e21dc84
zld_checksum_2=6b7d0e43486e5cd6bec65016032ce081
romfile_checksum_2=B65B
img_checksum_2=a1e743a41560dc3edcb22b943b199ec2
next_bootfrom=2
curr_bootfrom=2

Info size: 591/131068 bytes

NSA320>> ide reset

Reset IDE:
Marvell Serial ATA Adapter
Integrated Sata device found
[0 0 0]: Enable DMA mode (6)
  Device 0 @ 0 0:
Model: SAMSUNG HD501LJ                          Firm: CR100-10 Ser#: S0MUJ1MPXXXXXX
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
[0 1 0]: Enable DMA mode (6)
  Device 1 @ 0 1:
Model: ST4000DM005-2DP166                       Firm: 0001     Ser#:             XXXXXXXX
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 1718295.8 MB = 1678.0 GB (-775897424 x 512)


NSA320>> printenv
bootargs=console=ttyS0,115200 mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=/dev/nfs rw init=/init
bootcmd=nand read.e 0x2000000 $(kernel_addr) 0xA00000; bootm 0x2000000
bootdelay=2
baudrate=115200
loads_echo=0
eth1addr=00:19:CB:00:51:82
ipaddr=10.4.50.165
serverip=10.4.50.5
rootpath=/mnt/ARM_FS/
netmask=255.255.255.0
nandEcc=1bit
MODEL_ID=DD01
PRODUCT_NAME=NSA-320
FEATURE_BIT=00
CONTRY_TYPE=FF
VENDOR_NAME=ZyXEL Communications Corp.
run_diag=yes
ethaddr=B0:B2:DC:F0:FF:12
stdin=serial
stdout=serial
stderr=serial
console=console=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x7f00000@0x100000(root)
mainlineLinux=no
CASset=min
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
ethprime=egiga1
netbsd_en=no
vxworks_en=no
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;
disaMvPnp=no
ethmtu=1500
eth1mtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
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
hddPowerCtrl=no
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
enaAutoRecovery=yes
kernel_addr=0x4640000
pcieTune=no
ethact=egiga1

Environment size: 1558/131068 bytes

I have seen on this forum printenv output's of supposedly stock NSA320's with different values for kernel_addr, in one it was 0x4640000 and in another it was something like 0x8000000 (I can not remember the amount of zero's). So I do not know if this is possibly causing my issue.

Before I continue with trying to get Debian installed I would like to have this problem fixed, or is this not important, as I can get to the uboot prompt?

Could somebody point me in the right direction of what could be wrong with my NSA320 boot/nand's?

Cheers



Edited 6 time(s). Last edit at 03/08/2021 11:04AM by bandicoot.

bandicoot,

> Before I continue with trying to get Debian
> installed I would like to have this problem fixed,
> or is this not important, as I can get to the
> uboot prompt?

Correct. Since you still can boot to the u-boot prompt, and have serial console, there is no need to deal with stock error.

There 2 ways to boot into Debian from serial console. Both require you to create the Debian rootfs on USB first.

https://forum.doozan.com/read.php?2,12096

1. Create the rootfs on USB using Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2. Scroll down to the section:

Quote

Updated 25 Aug 2019:

Basic Debian buster Kirkwood rootfs for most Kirwood plugs:

- tarball size: 209M
- install size: 536M
- The init system used in this rootfs is sysvinit . To boot with systemd, see note 2 below.
- Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs server/client, iperf, ethtool, sysvinit-core, sysvinit, sysvinit-utils, u-boot-tools, and mtd-utils.
- see LED controls in /etc/rc.local, and /etc/init.d/halt
- see some useful aliases in /root/.profile
- root password: root

Download at Dropbox:

Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2

2. Method 1: You can boot directly from u-boot console using this instruction:

https://forum.doozan.com/read.php?2,102054,105374#msg-105374

This apprach requires you to do Step 4 (Create uImage with embedded DTB) on the rootfs instruction.

OR

3. Method 2: You can boot using kwboot to load the new u-boot image over UART:

https://forum.doozan.com/read.php?3,51739,51919#msg-51919

This apprach requires you to do skip Step 4 (Create uImage with embedded DTB) on the rootfs instruction.

After the loading is successful, you can boot straight into the USB Debian rootfs with boot command:

boot

=======

Between method 1 and 2, I would do method 2 (if you have another Linux box where you run serial console). Because if you can use kwboot loading the new u-boot over UART and run it, then you have a rescue mechanism for any problem now or future.

And also it does not require entering new u-boot envs (the new u-boot image internal envs are good enough to boot the USB rootfs).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi Bodhi,

Thanks so much for your help! I will give the instructions a go tomorrow. I have a fedora desktop machine, would for example the mkimage work correctly in fedora to create a kernelimage for the NSA320, or do I really need a Debian system for that as well?

Cheers

bandicoot,

> would for example the mkimage
> work correctly in fedora to create a kernelimage
> for the NSA320, or do I really need a Debian
> system for that as well?

Fedora is fine to create the USB rootfs on it.

The process of creating rootfs does not involve installing any specific kernel (it is already in the rootfs). So any Linux box would suffice.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi Bodhi,

The powersupply of my fedora desktop is dead, so I ended up creating a fedora usb stick to boot my laptop. I did everything you instructed and also ran in to long lines in stock uboot and had to use the second set you gave to Paul in the link you gave me for the booting instructions.

But now I ran into another issue on my NSA320. It appears the USB system is dead. It can not find the USB-stick I created the rootfs on (ext3).

I started looking for USB commands and tried them:

        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|
 ** MARVELL BOARD: RD-88F6281A LE

U-Boot 1.1.4 (Mar 23 2011 - 16:09:39) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM CS[1] base 0x10000000   size 256MB
DRAM Total size 512MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
//---  stateButtonBit = 3, recovery ---//
Kernel address is 0x4640000.

Streaming disabled
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  0
NSA320>> usb reset
(Re)start USB...
USB:   scanning bus for devices... 2 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
NSA320>> usb start
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
NSA320>> usb stop
stopping USB..
NSA320>> usb start
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
NSA320>> usb reset
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
NSA320>> usb reset
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
NSA320>> usb start
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
NSA320>>

I am assuming I should see with a 'USB reset' that I inserted the usb-stick like so (found that in another post):

Marvell>> boot
(Re)start USB...
USB:   scanning bus for devices... 2 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found

Is the USB system of my NSA320 now dead? Or is it something with the bios/rom or whereever the usb-drivers for uboot live?

If it is dead, what other options can you think of to revive my NSA320, like for example just use sata and a disk. And if this is an option, would the existing sata disk (500 GB ext3) with data on it be an option to just merge the rootfs into it, only /tmp is clashing with rootfs.

Cheers



Edited 1 time(s). Last edit at 03/11/2021 11:31AM by bandicoot.

Hi Bodhi,

I already managed to get it going on a hd replacing usb by ide in the boot sequence:

setenv ide_set_bootargs 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial'
setenv load_uimage 'ext2load ide 0:1 0x800000 /boot/uImage'
setenv load_uinitrd 'ext2load ide 0:1 0x2100000 /boot/uInitrd'
setenv ide_boot 'mw 0x800000 0 1; run load_uimage; run load_uinitrd; bootm 0x800000 0x2100000'
setenv ide_bootcmd 'run ide_set_bootargs; run ide_boot'
setenv bootcmd 'ide reset; ide start; run ide_bootcmd; ide stop; reset'

I also did the update and upgrade. So it is working now.

You wrote to run:

mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.2.9-kirkwood-tld-1 -d initrd.img-5.2.9-kirkwood-tld-1 uInitrd

If I see:

update-initramfs: Generating /boot/initrd.img-5.2.9-kirkwood-tld-1

in the update/upgrade.

But the original thing to do was for my case:

cp -a zImage-5.2.9-kirkwood-tld-1  zImage.fdt
cat dts/kirkwood-goflexnet.dtb  >> zImage.fdt
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.2.9-kirkwood-tld-1 -d zImage.fdt  uImage

Is the first mkimage the correct one then? Or should I run the second sequence again?

Cheers

bandicoot,


> Is the first mkimage the correct one then? Or
> should I run the second sequence again?

No, they are both correct for different purpose.

After you installed everything and do apt-get upgrade and see

update-initramfs: Generating /boot/initrd.img-5.2.9-kirkwood-tld-1

Then you need to regenerate uInitrd with

mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.2.9-kirkwood-tld-1 -d initrd.img-5.2.9-kirkwood-tld-1 uInitrd

The commands done during rootf creation was to create uImage (note the DTB for your box is kirkwood-nsa320.dtb):

cp -a zImage-5.2.9-kirkwood-tld-1  zImage.fdt
cat dts/kirkwood-nsa320.dtb  >> zImage.fdt
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.2.9-kirkwood-tld-1 -d zImage.fdt  uImage

So you can see that this uImage creation does not have anything to do with the initramfs.

======

At this point, if you want to go further, you should upgrade u-boot to the latest. But it is not necessary to run the new u-boot with the latest Linux kernel. You could stay with stock u-boot if you want to.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)