Real Dummy Guide

Hi Bodhi,

like Hans Peter (Zyxel NSA325 Newbie question), I have a NSA325 that I'd like to use with Debian (stock OS is too old/limited, the hardware too good to just throw it away). I have a fair basic knowledge of linux, but like Hans Peter, I feel like I'm missing sometimes a bit of information here and there and/or I'm not capable of tying the relevant parts together. So therefore, me too, I apologise right from the beginning for my partial ignorance ... ;-) but nevertheless, I'm trying to compile a real dummy guide for a first time installation and I have a couple of questions/issues:

1. NAND:

Marvell>> nand bad
Device 0 bad blocks:
03ea0000

Where is that block? is it safe to flash?

2: UART booting:
Didn't work for me - I always get the message "xmodem: Bad message" ...? (But I'm almost willing to go ahead like this and risk it ...)

3. Debian rootfs:
I prepared the stick as indicated, and Hans Peter's errors where a good guiding light. I also embedded the DTB (4. Create uImage with embedded DTB for booting with older u-boots). But I'm a bit confused about the next steps - do I have to execute the procedure from Re: how to backup/restore your NAND patitions and full device?

Thank you in advance for your support!

Joni

Joni,

> like Hans Peter
> (Zyxel
> NSA325 Newbie question), I have a NSA325
> that I'd like to use with Debian (stock OS is too
> old/limited, the hardware too good to just throw
> it away). I have a fair basic knowledge of linux,
> but like Hans Peter, I feel like I'm missing
> sometimes a bit of information here and there
> and/or I'm not capable of tying the relevant parts
> together. So therefore, me too, I apologise right
> from the beginning for my partial ignorance ...
> ;-)

Not at all :) we were all beginners at some point in time.


>but nevertheless, I'm trying to compile a real
> dummy guide for a first time installation and I
> have a couple of questions/issues:
>
> 1. NAND:
>

> Marvell>> nand bad
> Device 0 bad blocks:
> 03ea0000
>

>
> Where is that block? is it safe to flash?

This bad block is about 62MB in the NAND flash so it is far away from u-boot (the first 1MB). So it is safe to flash.

>
> 2: UART booting:
> Didn't work for me - I always get the message
> "xmodem: Bad message" ...? (But I'm almost willing
> to go ahead like this and risk it ...)

Now when you got "xmodem: Bad message', it is actually not bad. It means the NSA325 BootROM receive something, but it did not like. So check it you have used the option -p your kwboot command. Your kwboot command should look like:

kwboot  -t -B 115200 /dev/ttyUSB0 -b uboot.2017.07-tld-1.nsa325.mtd0.kwb -p

And if you get the same error "xmodem: Bad message" when you executing it again, then just hit up-arrow to recall the command and execute it again. Sometime the serial lines are noisy, and the NSA325 got some bad chars, so keep trying the kwboot command several times.

> 3. Debian rootfs:
> I prepared the stick as indicated, and Hans
> Peter's errors where a good guiding light. I also
> embedded the DTB
> (4.
> Create uImage with embedded DTB for booting with
> older u-boots).

You only want to append the DTB if you will run stock u-boot. After you've flashed new NSA325 u-boot image uboot.2017.07-tld-1.nsa325.mtd0.kwb, you need to boot with the original uImage on the rootfs.



> But I'm a bit confused about
> the next steps - do I have to execute the
> procedure from
> Re:
> how to backup/restore your NAND patitions and full
> device?

No need to do this. This is only if you need to reflash back to stock. The backup MTDs are good to have if you decide to go back to stock after flashing new u-boot.

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

Hi Bodhi,

thank you for your quick and kind reply.


> > 2: UART booting:
> > Didn't work for me - I always get the message
> > "xmodem: Bad message" ...? (But I'm almost
> willing
> > to go ahead like this and risk it ...)
>
> Now when you got "xmodem: Bad message', it is
> actually not bad. It means the NSA325 BootROM
> receive something, but it did not like. So check
> it you have used the option -p your kwboot
> command. Your kwboot command should look like:

I tried - as recommended - the UART booting first
UART Booting HowTo for Selected Kirkwood Devices
via the serial console (without the -p therefore):

./kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2013.10-tld-1-test.nsa325.uart.kwb

> again. Sometime the serial lines are noisy, and
> the NSA325 got some bad chars, so keep trying the
> kwboot command several times.

Hm, that's what I already did, but I'll keep trying (I start the device and quickly after - before the Marvell prompt appears - I launch the kwboot command, right?). Btw, is there a way to restart the device without unplugging it?

> > 3. Debian rootfs:
> You only want to append the DTB if you will run
> stock u-boot. After you've flashed new NSA325
> u-boot image uboot.2017.07-tld-1.nsa325.mtd0.kwb,
> you need to boot with the original uImage on the
> rootfs.

OK, so I would only need to append the DTB if I wanted to boot from the USB stick and flash uboot from there? And the easier way (given a serial console is available) would be to flash the newer uboot using kwboot via the serial console and then I can directly put in and boot from then rootfs that is on the USB stick?

Hi, me again - small update: the best I can get with the kwboot is

 0% [++xmodem: Bad message

... and on the other terminal window (screen), I can see that the box goes in some sort of limbo with a lot of weird characters ... ;-)

Joni,

Don't use that small u-boot. Download the latest NSA325 u-boot from the release thread:

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

scroll down to:

Quote

uboot.2017.07-tld-1.nsa325.bodhi.tar
md5
102be464341ec77de08725998dfca00b
sha256
93968d24efbe9fa1641f93340a4d3c476475c9d63f61573b365976d0770937ad

The command is:

kwboot  -t -B 115200 /dev/ttyUSB0 -b uboot.2017.07-tld-1.nsa325.mtd0.kwb -p

Yes, after you boot with kwboot, plug in the new Debian rootfs on USB and then after it booted into Debian prompt, flash u-boot from there.

Or you could install new u-boot from stock OS, too. However, important to do kwboot first, because it is a rescue method should things go wrong.

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

Hi Bodhi,

that worked and I was able to login to debian. I made the first modifications (generating the SSH keys, apt-get update etc.). By then I realized that I would not have the time to flash the new uboot and I quit debian. But the next time I tried to kwboot, I only got the following message (I cut the stuff above the loading):

97 % [......................................................................]
 99 % [....................................]
[Type Ctrl-\ + c to quit]


U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:42:03 -0700)
ZyXEL NSA325 2-Bay Power Media Server

SoC:   Kirkwood 88F6282_A1
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
MV88E1318 PHY initialized on egiga0
NSA325>

So kwboot loads the new uboot from my linux machine, but it fails to boot the USB debian. I also recreated the USB stick from scratch (because of the changes I made), but I end up with the same result. Booting from stock works normally. What did I do wrong? ... kwbooting bypasses the internal data on the NSA325, the kwboot on my linux machine is untouched, and the rootfs is new ...?

Joni,

> that worked and I was able to login to debian. I
> made the first modifications (generating the SSH
> keys, apt-get update etc.). By then I realized
> that I would not have the time to flash the new
> uboot and I quit debian.

Cool! great progress.

> But the next time I tried
> to kwboot, I only got the following message (I cut
> the stuff above the loading):

> NSA325>
>
> So kwboot loads the new uboot from my linux
> machine, but it fails to boot the USB debian.
> did I do wrong? ...

> kwbooting bypasses the
> internal data on the NSA325, the kwboot on my
> linux machine is untouched, and the rootfs is new
> ...?

kwboot does do anything permanent. So at the prompt you need to boot again

So with the new USB Debian rootfs attached. kwboot and interupt the countdown,

printenv
boot

And post the entire serial console log here.

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

OK, so, if I interrupt the kwboot countdown, I fall back to the teminal prompt; if I let the countdown go through to the prompt of the kwboot u-boot, OR if I let the box boot and interrupt the u-boot countdown of the stock u-boot, it gives me the same result on printev (see below).

Maybe I have a too mechanical perspective on this, but I don't understand where the envs (that are apparently not the correct ones) are stored - I recreated the files in /kwboot on the linux machine, I recreated the rootfs, and the stock boots like normal so where are they ...?

I was tempted to do the following:

Marvell>> resetenv
Marvell>> reset
Marvell>> saveenv
Marvell>> reset

But I think it's maybe better to ask beforehand ... ;-)

Log of printenv:

U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:42:03 -0700)
ZyXEL NSA325 2-Bay Power Media Server

SoC:   Kirkwood 88F6282_A1
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
MV88E1318 PHY initialized on egiga0
NSA325> 
NSA325> printenv
arch=sandbox
baudrate=115200
board=sandbox
board_name=sandbox
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_pci_enum=pci enum
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=host1 host0 
bootcmd_host0=setenv devnum 0; run host_boot
bootcmd_host1=setenv devnum 1; run host_boot
bootdelay=2
bootm_size=0x10000000
cpu=sandbox
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
eth1addr=00:00:11:22:33:45
eth3addr=00:00:11:22:33:46
eth5addr=00:00:11:22:33:47
ethact=egiga0
ethaddr=00:00:11:22:33:44
fdt_addr_r=0xc00000
host_boot=if host dev ${devnum}; then setenv devtype host; run scan_dev_for_boot_part; fi
ipaddr=1.2.3.4
kernel_addr_r=0x1000000
pxefile_addr_r=0x2000
ramdisk_addr_r=0x2000000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x1000
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts init=/bin/systemd
stderr=serial
stdin=serial
stdout=serial
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi

Environment size: 2210/131068 bytes

Joni,

> fall back to the teminal prompt; if I let the
> countdown go through to the prompt of the kwboot
> u-boot, OR if I let the box boot and interrupt the
> u-boot countdown of the stock u-boot, it gives me
> the same result on printev (see below).

I see.

>
> Maybe I have a too mechanical perspective on this,
> but I don't understand where the envs (that are
> apparently not the correct ones) are stored - I
> recreated the files in /kwboot on the linux
> machine, I recreated the rootfs, and the stock
> boots like normal so where are they ...?

This looks like newer setup for later NSA325 FW version. What you see it not the envs from U-Boot 2017.07-tld-1 image that you're kwbooting. And they are not from stock envs either. They are in sandbox that somehow were flashed already, either by the manufacterer or by previous owner of this box (if you bought it used).

Looks like the sandbox envs is now at the same location as my u-boot build. Which is a little bit confusing!

But disregard them. They are useless.

>
> I was tempted to do the following:
>
>

> Marvell>> resetenv
> Marvell>> reset
> Marvell>> saveenv
> Marvell>> reset
>

>
> But I think it's maybe better to ask beforehand
> ... ;-)

Yes, that's a very good thinking :) doing that could have messed up things really bad. The rules of thumb is that never do anything that modifies the u-boot envs while instlaling, except what was instructed in the installation thread. So no saveenv or resetenv should be executed ever.

===

Now we know you can kwboot the new u-boot version. You can either:

1. Boot back to stock OS, and follow the instruction in the released thread to flash uboot.2017.07-tld-1.nsa325.mtd0.kwb. And then plug in the new rootfs Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2 on USB. And try booting.

2. Try booting to the new rootfs Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2 on USB with kwboot. And this will need further instruction to load the envs image that matches uboot.2017.07-tld-1.nsa325.mtd0.kwb into memory and run it.

Let me know which option you prefer.

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

Hi bodhi,

(as I started with the article on Nas central (a while ago ...), I have used saveenv / resetenv beforehand ... not not recently.)

Given my rather unproductive and unsuccessful experiences with stock OS (I was not able to get anywhere with the instructions form the u-boot thread with the Marvell prompt in stock), I would choose option #2 - but I think you'd be better at estimating what is easier/safer?

Joni

Joni,

The easiest is booting with kwboot and load the correct default envs using this instruction:

https://forum.doozan.com/read.php?3,29362,29390#msg-29390

Note that the DTB name is different

setenv dtb_file '/boot/dts/kirkwood-nsa325.dtb'

So basically you are almost there. You just need the correct set of default envs to be able to boot Debian using kwboot. After booting into Debian, you can flash new u-boot and it default envs images at Linux prompt.

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

Hi bodhi,

worked like a charm. I am now in the middle of the uboot flash procedure. But the result of step 6 is not as expected:

root@debian:/# flash_erase /dev/mtd0 0 4
Erasing 128 Kibyte @ 7f563f5c00000064 --  4 % complete

What should I do???



Edited 1 time(s). Last edit at 05/05/2019 05:16AM by JoniDaBoni.

Joni,

> root@debian:/# flash_erase /dev/mtd0 0 4
> Erasing 128 Kibyte @ 7f563f5c00000064 -- 4 %
> complete

Don't worry about it. That flash_erase version does not give sane output. But it actually did erase successfully. Go ahead and flash with nandwrite.

If nandwrite does not reports any error then it's all good!

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

Thank you for the confirmation ... worked as expected. So I continue with step 8 ?!

Hi bodhi,

I'm now stuck a 8.2e - in the saved envs, there are no mtdparts - and the ethaddr looks interesting ...?

bootargs=
bootcmd=
bootdelay=2
baudrate=115200
arch=sandbox
cpu=sandbox
board=sandbox
board_name=sandbox
stdin=serial,cros-ec-keyb,usbkbd
stdout=serial,vidconsole
stderr=serial,vidconsole
ethaddr=00:00:11:22:33:44
eth1addr=00:00:11:22:33:45
eth3addr=00:00:11:22:33:46
eth5addr=00:00:11:22:33:47
ipaddr=1.2.3.4
host_boot=if host dev ${devnum}; then setenv devtype host; run scan_dev_for_boo$
boot_net_pci_enum=pci enum
boot_net_usb_start=usb start
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev$
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_script_dhcp=boot.scr.uimg
boot_targets=host1 host0
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr}$
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${pref$
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${pref$
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${$
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for$
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env e$
bootcmd_host1=setenv devnum 1; run host_boot
bootcmd_host0=setenv devnum 0; run host_boot
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
bootm_size=0x10000000
kernel_addr_r=0x1000000
fdt_addr_r=0xc00000
ramdisk_addr_r=0x2000000
scriptaddr=0x1000
pxefile_addr_r=0x2000
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=1$

But the result of fw_printenv gives me:

root@debian:/tmp# fw_printenv | more
bootcmd_exec=run load_uimage; if run load_initrd; then if run load_dtb; then boo
tm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_a
ddr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - 
$load_dtb_addr; else bootm $load_uimage_addr; fi; fi
bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
bootdelay=10
bootdev=usb
device=0:1
devices=usb ide mmc
disks=0 1 2 3
ethact=egiga0
ethaddr=52:3b:20:9c:11:51
if_netconsole=ping $serverip
ipaddr=192.168.0.231
led_error=orange blinking
led_exit=green off
led_init=green blinking
load_dtb_addr=0x1c00000
load_initrd_addr=0x1100000
load_uimage_addr=0x800000
load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device $load_dtb_addr $dtb_file
load_initrd=echo loading uInitrd ...; load $bootdev $device $load_initrd_addr /boot/uInitrd
load_uimage=echo loading uImage ...; load $bootdev $device $load_uimage_addr /boot/uImage
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start"; 
 setenv scan_ide "ide reset";  setenv scan_mmc "mmc rescan"; for dev in $devices
; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for di
sknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; 
if load $dev $disknum:1 $load_uimage_addr /boot/uImage 1; then scan_done=1; echo
 Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev
 $dev; fi; fi; done; fi; done
serverip=192.168.0.220
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10
 $mtdparts $custom_params
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; se
tenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
uenv_addr=0x810000
uenv_import=echo importing envs ...; env import -t $uenv_addr $filesize
uenv_init_devices=setenv init_usb "usb start";  setenv init_ide "ide reset";  se
tenv init_mmc "mmc rescan"; for devtype in $devices; do run init_$devtype; done;
uenv_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices; 
 do for disknum in 0; do run uenv_read_disk; done; done;
uenv_read_disk=if test $devtype -eq mmc; then if $devtype part; then run uenv_re
ad;  fi; else if $devtype part $disknum; then run uenv_read; fi;  fi
uenv_read=echo loading envs from $devtype $disknum ...; if load $devtype $disknu
m:1 $uenv_addr /boot/uEnv.txt; then setenv uenv_loaded 1; fi
usb_ready_retry=15
arcNumber=4495
dtb_file=/boot/dts/kirkwood-nsa325.dtb
root@debian:/tmp#

Looks better to me, but the IP address is not correct yet (should be 192.168.178.66). Using the following commands, I can set the device's IP and the server IP address, right?

fw_setenv ipaddr   '192.168.178.66'
fw_setenv serverip '192.168.178.1'

So ... is it safe to reboot?

And another question: if I create an ISO file of the rootfs USB stick, can I use this like a backup (to rebuild it on another stick in case I need it?)

Joni,

> But the result of fw_printenv gives me:

The envs look OK.

> Using the
> following commands, I can set the device's IP and
> the server IP address, right?
>

> fw_setenv ipaddr   '192.168.178.66'
> fw_setenv serverip '192.168.178.1'
>

Yes.

> So ... is it safe to reboot?


Yes. The ethaddr can be changed later in Debian using fw_setenv. The ethaddr in the default envs is set to a default local MAC address.

ethaddr=52:3b:20:9c:11:51

>
> And another question: if I create an ISO file of
> the rootfs USB stick, can I use this like a backup
> (to rebuild it on another stick in case I need
> it?)

See the Wiki thread for how to back up the rootfs.

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

Quote

Backup and Cloning rootfs

CrashPlan 4.3.0
Backup/Restore rootfs using tar command
Adjust udev rules after cloning rootfs
Stock Pogoplug rootfs
How to clone a rootfs from one Kirkwood box to another: Step 1 and Step 2
How to clone SATA rootfs to USB rootfs

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