NAS326 booting problem

Hi again bodhi,

After the successful installation of your Debian at NSA310S, I am now trying the same for a NAS326. I tried the zyxelOS fw_setenv methods, didn't worked, so decided to go for the serial console.

Created an ext3 drive (4gb, only 1 partition), with "rootfs" label, copied the Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 file on it, after untar made the uImage and copied all the envs.

Started a monitoring kwboot session as you suggested and rebooted.

Unfortunately it is not booting as the dtb file is invalid. I tried 2 different dtbs (one within the package and one from this forum), neither of them is working. I did the mkimage as well.

My /boot, /boot/dts directories and what I did with them: https://pastebin.com/u46RXL4p

My u-boot bootlog is here: http://pastebin.com/JG5MTCEN

Printenv: http://pastebin.com/b5UGKpvZ

Do you have any idea what am I messing up with this box too? :)



Edited 5 time(s). Last edit at 06/19/2020 12:53PM by cyraxxx.

cyraxxx,

You did not follow the installation correctly.

https://forum.doozan.com/read.php?2,88619,94989#msg-94989

Quote

I'm in the process of updating the installation instruction for this box to boot with rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 or later.

For 1st time installation, please use the instruction below to install using Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2 rootfs in the instruction. And then upgrade the kernel to the latest version (see Section E at the end of the instruction).

To make things simple for 1st time installation, the rootfs is kept at Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2. And then in Section E, you can find out how to upgrade the kernel to the latest.

Nothing too complicate, I simply did not have time to modify the installation instruction to use Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2, because there are u-boot envs changes. And whenever I change u-boot envs in the installation, I need to do regression test.


Now, what you did was using the latest rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 (which is OK for advance users if you already know what to do). But you need to read Section E to know why the instruction uses Debian-4.9.0-mvebu-tld-12-rootfs-bodhi.tar.bz2.

Quote

E. Instruction for kernel upgrade after installation

Starting kernel version 5.2.9-mvebu-tld-1, we need to boot with uImage. So please follow a special upgrade instruction here to upgrade the kernel from 4.9.0-mvebu-tld-12 to the latest:

https://forum.doozan.com/read.php?2,88619,94989#msg-94989

Quote
https://forum.doozan.com/read.php?2,88619,94989#msg-94989


2. Modify u-boot envs

If you have serial console connected, the envs change below can be executed at serial console prompt using setenv, too. As a matter of fact, testing these modification using serial console is recommended (to avoid committing the changes until you can boot successfully).

2.a. USB rootfs

fw_setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/uImage; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootm $load_image_addr $load_initrd_addr'

========

Since you have serial console, just do

setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/uImage; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootm $load_image_addr $load_initrd_addr'

And

boot

After it booted. In Debian, make it permanent.

fw_setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/uImage; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootm $load_image_addr $load_initrd_addr'

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

Thanks for your infos, it is working now.

You were right, I haven't followed exactly, but the problem was that in one article it was talking about 5.2.9 and in an other 4.9.0 :) Also haven't noticed the difference (uImage vs zImage) so I thought why wouldn't I start with 5.2.9...wasn't the brightest idea as a novice :D

My current setup (which is working very well) is: 5.2.9 kernel boots from usb, rootfs on a ext4 HDD and there is an other HDD in the box for backups. (I wanted to put kernel on the hdd too, but in that forum message there is a 'TBD' mark and also some kind of a delay problem, so I decided not to play with it)

The usb drive is mounted under /mnt/drive and I symlinked the /mnt/drive/boot -> /boot to look like as the original one rootfs. Can I update in this setup to the last kernel (5.6.9)? I am worried about one step (dpkg -i linux-image-5.6.9-mvebu-tld-1_1.0_armhf.deb), because in my case the rootfs is not the same as the kernel drive and I have no idea what is that package doing :D

Sorry for my noob questions, unfortunately I am rarely using Linux especially not an embedded, special version of that. And if I don't update while I remember at least something, I will never do it :)

And one more thing: is it possible somehow to donate you a coffee/beer/whatever your drug is?



Edited 1 time(s). Last edit at 06/20/2020 05:34PM by cyraxxx.

cyraxxx,

> You were right, I haven't followed exactly, but
> the problem was that in one article it was talking
> about 5.2.9 and in an other 4.9.0 :)

Yeah :) I think I will revise that again to avoid confusion.


> The usb drive is mounted under /mnt/drive and I
> symlinked the /mnt/drive/boot -> /boot to look
> like as the original one rootfs. Can I update in
> this setup to the last kernel (5.6.9)? I am
> worried about one step (dpkg -i
> linux-image-5.6.9-mvebu-tld-1_1.0_armhf.deb),
> because in my case the rootfs is not the same as
> the kernel drive and I have no idea what is that
> package doing :D
>

That's a good configuration! rootfs on HDD is best if you don't use RAID.

When you upgrade, dpkg will create the kernel files and modules on the HDD rootfs. Pretend everything is on this HDD rootfs. After you done the kernel installation, copy the uImage, uInitrd, and the DTB over to that /boot. If dpkg follow the link to the USB /boot, then you need to be aware that the drives don't have the same set of files. Thus you need to copy them from one drive /boot to another so you have a complete kernel files set on both.

What I would do is not to use symlink. Just have the whole rootfs on HDD, and copy the /boot folder from HDD to the USB drive after each kernel upgrade.


> And one more thing: is it possible somehow to
> donate you a coffee/beer/whatever your drug is?

I won't tell you my drug of choice :) for donation, see my signature: bodhi's corner

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

Actually that revise would be quite easy, you only need to delete the 4.9 parts in that post (and change the envs' part) :) However in that case the kernel at hdd section would be incomplete as it is not solved after 5.2.

Upd.: now I re-read the things to reconstruct why I didn't pay attention for the details as you also said. As a "feedback", I write how I mesed up, maybe it helps others or you to know what can be messed up as a novice :) In the common topic (Linux Kernel 5.6.9 MVEBU package and Debian armhf rootfs) the instructions are only about 5.2.9 as first-time installer. In that specific part (10 Sep 2019 ) it mentions that users need to update the envs ("further u-boot envs setup is needed"). And yes, there is the sentence I haven't followed ("Note that from kernel version 5.2.9-mvebu-tld-1, we need to boot with..."). The ned of modifing the envs leads to the device-specific topic (in my case Zyxel NAS326 Installation Instruction), where you also stated that it will be updated for 5.2.9, and then continues with 4.9.0 as first timer install - however for a random ad-hoc linux user the uImage and zImage almost look the same :D

Anyway, thank you for your advices about these devices and configurations. Unfortunately I am not related to Linux so without you, these devices would have been stuck on the memory consuming original systems.

Really thank you for your help and your whole work on these devices. And the fact that your donations goes for a charity organizations...man, you are awesome.

Keep up the good work and don't get bored of the lames like me :)



Edited 1 time(s). Last edit at 06/22/2020 02:07PM by cyraxxx.

cyraxxx ,

> Actually that revise would be quite easy, you only
> need to delete the 4.9 parts in that post (and
> change the envs' part) :) However in that case the
> kernel at hdd section would be incomplete as it is
> not solved after 5.2.

Sure, it is easy, nothing complicate. But as always, the instruction must be tested before I modify the post, no matter how trivial it is. So I need to actually do it, or somebody will do it to confirm that it works.

Would you like to try the HDD installation on a spare HDD? I can revise it and you will test it.

> Keep up the good work and don't get bored of the
> lames like me :)

Not at all :) Thanks to you I can see that I need to repeat the old description for these MVEBU boxes in the kernel release. This is due to the fact that we still run these boxes with stock U-Boot. So each box has a different installation.

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

Of course, if you think that I am capable then I happily say yes :D On this week I am away from the NAS326, but after that I will be at home, and also got some unused spare disks/usb drives, so why not :)

cyraxxx ,

Ok, great:) Let me know when you are ready!

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

Hey,

I am at home, so ready to follow your instructions :)

cyraxxx,

Here is the revised Zyxel NAS326 Installation instruction. All 3 methods are updated to use with the 5.2.9 rootfs.

The entire instruction post is below. As a rule of thumb for regression testing, you need to execute each step in the procedure to verify that it works (don't figure out the difference and only doing that).

Once you can test and verify that the HDD method works (even better if you can repeat the USB installation!), I will edit the installation thread to use this instruction.

Thanks!

============


Zyxel NAS326 Installation for rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2
Updated 04 Jul 2020


Installation Instruction

Installation for NAS326 box can be done with serial console connected (section A), or inside stock OS and without serial console (section B for USB rootfs, section C for SATA rootfs). Note: for section A and B, the USB rootfs must be inserted to the front USB port (USB 2.0).

Prerequisite

Prepare the rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 on USB or HDD as described in the rootfs release thread (scroll down to section Updated 10 Sep 2019).


A. Instruction for the booting the NAS326 with a USB rootfs (serial console setup)

A1. Requirements

1. Serial console connected during set up (which should be removed later during normal operation).

2. Download either the latest ARM32 version or the x86-64 version of kwboot. Use it depending on the architecture of serial console converter host. Please see this post for ARM32 kwboot. (I'll need to recompile the x86-64 version and reupload).

3. Prepare the rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 as described in the Debian rootfs release section:

Quote

Updated 04 Feb 2017:

This Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 has been uploaded.

A2. Installation

Warning: Step 4 in the instruction in this section uses a "env/code injection" to replace the Zyxel NAS326 stock u-boot bootcmd with a different command during boot. It's a simple trick that change u-boot env bootcmd (it does not touch u-boot binary in NAND). However, this hack should not be used on a different MVEBU box (any box other than the NAS326). Doing this without examining your box's stock u-boot source code could likely messing up your u-boot envs and prevent booting, or in the worse case bricking it. Please post questions regarding installation for other MVEBU boxes, it might be possible to do this.

1. Start kwboot on the serial console host

For ARM32 kwboot:

./kwboot -t -B 115200 /dev/ttyUSB0 -d

For x86-64 kwboot:

./kwboot -t -B 115200 /dev/ttyUSB0

2. Power up the NAS326, and wait at serial console, observe kwboot spinning / while waiting for handshake.

3. After a period of time, the NAS326 will time out and start booting its stock u-boot. Interrupt u-boot at countdown. Get a listing of your current u-boot envs, and save it to a notepad in case you want to restore it later.

printenv

4. Enter the following commands (copy/paste each line to the u-boot prompt).

setenv curr_bootfrom 1
setenv next_bootfrom 1
setenv load_initrd_addr 0x2900000
setenv load_image_addr 0x02000000
setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start'
setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2"'
setenv bootcmd_stock_1 'run set_bootargs_stock; echo Booting from NAND kernel 1 ...; nand read 0x2000000 0x00E00000 0xF00000 && bootz 0x2000000'
setenv bootcmd_stock_2 'run set_bootargs_stock; echo Booting from NAND kernel 2 ...; nand read 0x2000000 0x08700000 0xF00000 && bootz 0x2000000'
setenv usb_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial"'
setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/uImage; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootm $load_image_addr $load_initrd_addr'
setenv bootcmd_custom 'if run usb_bootcmd; then; else if run bootcmd_stock_1; then; else run bootcmd_stock_2; reset; fi; fi'
setenv kernel_addr_1 '0x00000000; run bootcmd_custom; '
saveenv

5. Reset the NAS326, exit kwboot.

reset

And then press "Control \ c" to exit kwboot

6. Start kwboot again on the serial console host (use the same command as in step 1)

7. After a period of time, the NAS326 will time out and start booting its stock u-boot. Observe kernel loading and booting until seeing the Debian prompt. At this point we can either login directly with serial console, or by SHH. If login is through SSH, find the NAS:

ping debian.local

When the ping returns successful response, then login (root password is root);

ssh root@debian.local

If for whatever reason (e.g. firewall), the NAS326 cannot be found as debian.local, then find its IP in the router webpage. Or use a scanning app such as Linux nmap or IOS Fing to find the IP.

8. DONE.


A3. Normal Operation

The USB rootfs should be plugged in permanently, and the serial console module should be removed.

1. Whenever the NAS326 is rebooted or cold started, to boot without manual intervention, the serial console module must be unplugged from the NAS326. If the serial console module is plugged in, then step 1 in the installation instruction A2 must be executed (so that the NAS326 will continue booting when it detected the serial console present). Note that reboot in some instance will work with serial console plugged in.

2. If you want to boot back to stock OS in NAND, just shutdown the box, unplug the USB and power up the box. It will boot the kernel 1 in NAND and then if not successful, it will try kernel 2.

This also serves as a rescue system. Whenever the rootfs on USB has problem and cannot boot (the effect is just like the USB drive is not plugged in), the NAS326 will fall back to booting the kernel 1 or 2 in NAND. When this occurs, the u-boot envs in step 4 must be reentered at serial console again to allow booting back to USB rootfs.

3. Setup WOL.

Add this line to your /etc/rc.local

/usr/sbin/i2cset -y 0x0 0xa 0xa 0x0006 w

For more info about WOL, see this post


A4. Reverse to stock OS permanently

To reverse the setup, and boot back to stock NAND kernel permanently, execute the following instructions at serial console:

setenv kernel_addr_1 0x00E00000
setenv bootargs 'console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2'
saveenv
boot

B. Instruction for booting the NAS326 with a USB rootfs (setup without serial console)

B1. Deprecated

B2. Installation

Warning: Step 4 in the instruction in this section uses a "env/code injection" to replace the Zyxel NAS326 stock u-boot bootcmd with a different command during boot. It's a simple trick that change u-boot env bootcmd (it does not touch u-boot binary in NAND). However, this hack should not be used on a different MVEBU box (any box other than the NAS326). Doing this without examining your box's stock u-boot source code could likely messing up your u-boot envs and prevent booting, or in the worse case bricking it. Please post questions regarding installation for other MVEBU boxes, it might be possible to do this.

1. Gain SSH to the NAS326 box.

Use the Zyxel NAS326 instruction (came with the box) for logging as admin user through the web page of the box, set password, and Enable SSH.

2. Open a termimal and connect to the NAS326 with SSH, and login to the box as root user.

3. After logging in, get a listing of your current u-boot envs, and save it to a notepad in case you want to restore it later.

fw_printenv

4. Enter the following commands (copy/paste each line to the stock OS command line).

fw_setenv curr_bootfrom 1
fw_setenv next_bootfrom 1
fw_setenv load_initrd_addr 0x2900000
fw_setenv load_image_addr 0x02000000
fw_setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start'
fw_setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2"'
fw_setenv bootcmd_stock_1 'run set_bootargs_stock; echo Booting from NAND kernel 1 ...; nand read 0x2000000 0x00E00000 0xF00000 && bootz 0x2000000'
fw_setenv bootcmd_stock_2 'run set_bootargs_stock; echo Booting from NAND kernel 2 ...; nand read 0x2000000 0x08700000 0xF00000 && bootz 0x2000000'
fw_setenv usb_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial"'
fw_setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/uImage; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootm $load_image_addr $load_initrd_addr'
fw_setenv bootcmd_custom 'if run usb_bootcmd; then; else if run bootcmd_stock_1; then; else run bootcmd_stock_2; reset; fi; fi'
fw_setenv kernel_addr_1 '0x00000000; run bootcmd_custom; '
fw_setenv change_boot_part 1

And then list the u-boot envs again, and save it to a notepad in case there is problem with booting and it needs to be referenced.

fw_printenv

5. Plug in the USB rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2, and reboot

sync
sync
/sbin/reboot

7. After a period of time, the NAS326 will start rebooting. Wait for about 30 seconds and login through SSH.

To find the NAS:

ping debian.local

When the ping returns successful response, then login (root password is root);

ssh root@debian.local

If for whatever reason (e.g. firewall), the NAS326 cannot be found as debian.local, then find its IP in the router webpage. Or use a scanning app such as Linux nmap or IOS Fing to find the IP.

8. DONE.


B3. Normal Operation

The USB rootfs should be plugged in permanently, and if there is serial console module attached before then it should be removed during booting.

1. Whenever the NAS326 is rebooted or cold started, to boot without manual intervention, the serial console module must be unplugged from the NAS326. If the serial console module is plugged in, then step 1 in the Section A2 installation instruction must be executed (so that the NAS326 will continue booting when it detected the serial console present). Note that reboot in some instance will work with serial console plugged in.

2. If you want to boot back to stock OS in NAND, just shutdown the box, unplug the USB and power up the box. It will boot the kernel 1 in NAND and then if not successful, it will try kernel 2.

This also serves as a rescue system. Whenever the rootfs on USB has problem and cannot boot (the effect is just like the USB drive is not plugged in), the NAS326 will fall back to booting the kernel 1 or 2 in NAND. When this occurs, the u-boot envs in step 4 must be reentered at Debian command line again to allow booting back to USB rootfs.

3. Setup WOL.

Add this line to your /etc/rc.local

/usr/sbin/i2cset -y 0x0 0xa 0xa 0x0006 w

For more info about WOL, see this post


B4. Reverse to stock OS permanently

To reverse the setup, and boot back to stock NAND kernel permanently, execute the following instructions at the Debian command line:

fw_setenv kernel_addr_1 0x00E00000
fw_setenv bootargs 'console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2'

and then reboot

sync
shutdown -r now

C. Instruction for booting the NAS326 with rootfs on internal HDD (setup without serial console)

C1. Deprecated

C2. Installation

Warning: Step 4 in the instruction in this section uses a "env/code injection" to replace the Zyxel NAS326 stock u-boot bootcmd with a different command during boot. It's a simple trick that change u-boot env bootcmd (it does not touch u-boot binary in NAND). However, this hack should not be used on a different MVEBU box (any box other than the NAS326). Doing this without examining your box's stock u-boot source code could likely messing up your u-boot envs and prevent booting, or in the worse case bricking it. Please post questions regarding installation for other MVEBU boxes, it might be possible to do this.

1. Gain SSH to the NAS326 box.

Use the Zyxel NAS326 instruction (came with the box) for logging as admin user through the web page of the box, set password, and Enable SSH.

2. Open a termimal and connect to the NAS326 with SSH, and login to the box as root user.

3. After logging in, get a listing of your current u-boot envs, and save it to a notepad in case you want to restore it later.

fw_printenv

4. Enter the following commands (copy/paste each line to the stock OS command line).

fw_setenv curr_bootfrom 1
fw_setenv next_bootfrom 1
fw_setenv load_initrd_addr 0x2900000
fw_setenv load_image_addr 0x02000000
fw_setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2"'
fw_setenv bootcmd_stock_1 'run set_bootargs_stock; echo Booting from NAND kernel 1 ...; nand read 0x2000000 0x00E00000 0xF00000 && bootz 0x2000000'
fw_setenv bootcmd_stock_2 'run set_bootargs_stock; echo Booting from NAND kernel 2 ...; nand read 0x2000000 0x08700000 0xF00000 && bootz 0x2000000'
fw_setenv sata_init 'mw.l f1018100 20420000; mw.l f1018140 003ca800; sleep 3; scsi init'
fw_setenv sata_bootcmd 'echo Booting from SATA ...; setenv fdt_skip_update yes; run sata_init; ext2load scsi 0:1 $load_image_addr /boot/uImage; ext2load scsi 0:1 $load_initrd_addr /boot/uInitrd; run sata_set_bootargs; bootm $load_image_addr $load_initrd_addr'
fw_setenv sata_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial"'
fw_setenv bootcmd_custom_sata 'if run sata_bootcmd; then; else if run bootcmd_stock_1; then; else run bootcmd_stock_2; reset; fi; fi'
fw_setenv bootcmd_custom 'run bootcmd_custom_sata'
fw_setenv kernel_addr_1 '0x00000000; run bootcmd_custom; '

And then list the u-boot envs again, and save it to a notepad in case there is problem with booting and it needs to be referenced.

fw_printenv

5. Insert the HDD with rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2, if not already inside the box, and reboot

sync
sync
/sbin/reboot

7. After a period of time, the NAS326 will start rebooting. Wait for about 30 seconds and login through SSH.

To find the NAS:

ping debian.local

When the ping returns successful response, then login (root password is root);

ssh root@debian.local

If for whatever reason (e.g. firewall), the NAS326 cannot be found as debian.local, then find its IP in the router webpage. Or use a scanning app such as Linux nmap or IOS Fing to find the IP.

8. DONE.


C3. Normal Operation

The HDD rootfs should be plugged in permanently, and if there is serial console module attached before then it should be removed during booting.

1. Whenever the NAS326 is rebooted or cold started, to boot without manual intervention, the serial console module must be unplugged from the NAS326. If the serial console module is plugged in, then step 1 in the Section A2 installation instruction must be executed (so that the NAS326 will continue booting when it detected the serial console present). Note that reboot in some instance will work with serial console plugged in.

2. If you want to boot back to stock OS in NAND, just shutdown the box, remove the HDD rootfs and power up the box. It will boot the kernel 1 in NAND and then if not successful, it will try kernel 2.

This also serves as a rescue system. Whenever the rootfs on HDD has problem and cannot boot (the effect is just like the HDD drive is not plugged in), the NAS326 will fall back to booting the kernel 1 or 2 in NAND. When this occurs, the u-boot envs in step 4 must be reentered at Debian command line again to allow booting back to HDD rootfs.

3. Setup WOL.

Add this line to your /etc/rc.local

/usr/sbin/i2cset -y 0x0 0xa 0xa 0x0006 w

For more info about WOL, see this post


C4. Reverse to stock OS permanently

To reverse the setup, and boot back to stock NAND kernel permanently, execute the following instructions at the Debian command line:

fw_setenv kernel_addr_1 0x00E00000
fw_setenv bootargs 'console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2'

and then reboot

sync
shutdown -r now

D. Notes

D.1. HDD rootfs quirks

For HHD booting issues after your installation, see this thread.


D.2. NAS326 Serial console pinouts

          +----+----+           
          |    |    |
+----+----+----+----+----+
|3.3V| TX | RX |    | GND|
+----+----+----+    +----+

D.3. NAS325 Serial console header Pic

The Zyxel NAS326 and the NSA325 serial header pinouts and locations are identical on these boards. I've attached the NSA2325 board pic to this post here to show the header location. If anybody has a better pic for NAS326 please post.

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

Okay, I will do them, but I have two questions:

First: can I modify the setenvs from the running debian system or should I boot to zyxelOS and doing from there? Normally I wouldn't ask that, but you said I need to follow every steps exactly :)
Second: Do you want me to do the serial console installation ('A') or just 'B' and 'C'?

Hi cyraxxx,

> First: can I modify the setenvs from the running
> debian system

Sure, do it in Debian, or serial console. As long as all the setenvs are executed.

> Second: Do you want me to do the serial console
> installation ('A') or just 'B' and 'C'?

I think B and C would be enough (they were copied/pasted from A and then modified).

Thanks!

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

OK, I will do the tests in the forthcoming days and let you know if I am done.

A little bit offtopic question: isn't it possible to install the Debian kernel somehow to the nand memory (replacing original kernel1 or kernel2)? It would almost the same as the USB boot, but maybe the NAND is more reliable then a USB drive :)

cyraxxx,

> A little bit offtopic question: isn't it possible
> to install the Debian kernel somehow to the nand
> memory (replacing original kernel1 or kernel2)?

Of course it is possible. But I would not recommend that. Since the rootfs is on either USB or HDD, there is no point storing the kernel files on NAND. There are a lot of disadvantages in booting kernel files from NAND (certainly the disadvantages is way more than a little benefit gain from doing that).

NAND could be used to install a complete rescue system (kernel files and rootfs). That would be worth doing.

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



Edited 1 time(s). Last edit at 07/05/2020 11:10PM by bodhi.

Okay, I am done succesfully.

As I have a working USB boot method, to change it, first I tried with the HDD (C) method with a spare HDD drive - it wasn't working (I think one of my USB ports is dying so useage of the SATA -> USB converter wasn't a great idea :D )
Then I booted to the zyxelOS, setted up the envs for USB booting - it went well. Then from that USB debian setted up the envs again for HDD booting (then used an other USB port on my computer to make to the rootfs).
Then I tried to boot from HDD rootfs - it went well this time.
So after that I setted up again for USB booting (to restore my original configuration), put back the original HDDs and now it is working as before I started the test -> everything is OK.

Fortunately I didn't have to use the serial cable, so didn't tried the 'A' version.

A suggestion:
In section C2 (beside of the missing number 6 :D ), there is this part:

____________________________________________________________________________
5. Insert the HDD with rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2, if not already inside the box, and reboot

sync
sync
/sbin/reboot
____________________________________________________________________________

It is maybe confusing as:
-if you make this rootfs from zyxelOS to an internal HDD, you don't need to insert (but you can run the commands)
-if you make this rootfs on an other computer (like me), first you need to turn off the NAS, insert the HDD and then you can run these commands - which I cannot understand exactly why they are neccessary, because in that phase you can easy modify the envs to instantly boot to HDD rootfs next time

cyraxxx,


> A suggestion:
> In section C2 (beside of the missing number 6 :D
> ), there is this part:
>
> ____________________________________________________________________________
> 5. Insert the HDD with rootfs
> Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2, if
> not already inside the box, and reboot
>
> sync
> sync
> /sbin/reboot
> ____________________________________________________________________________
>
> It is maybe confusing as:
> -if you make this rootfs from zyxelOS to an
> internal HDD, you don't need to insert (but you
> can run the commands)
> -if you make this rootfs on an other computer
> (like me), first you need to turn off the NAS,
> insert the HDD and then you can run these commands
> - which I cannot understand exactly why they are
> neccessary, because in that phase you can easy
> modify the envs to instantly boot to HDD rootfs
> next time

Good point! even though you could insert the HDD while the system is running without problem, I should mention that shutdown-insert HDD-and power up, is a better practice.

Sync is always something users should always do before reboot. That was a reminder, no matter what case, sync before reboot is good safe practice (reboot does issue a sync, but you'll never know if it is enough).

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

Hi,

Thanks for explanation and your overall work again.

If you need to do some tests in the future, you can tell me (if not that difficult :D ). If I am available I will do that (I can test on NAS326 and NSA310S).

Best regards,
cyraxxx

Hi cyraxxx,

> If you need to do some tests in the future, you
> can tell me (if not that difficult :D ). If I am
> available I will do that (I can test on NAS326 and
> NSA310S).

Thanks! good collaborator like you is hard to find :) I will ask for your help if I get back to this NAS326 box to try the last thing I did not get it to work: UART booting (running kwboot to load u-boot over the serial connection). This box timing is quite difficult to figure out. It was too time consuming, and there is no urgent need, so I stopped.

FYI, the working thread for this box is 14-page long!
https://forum.doozan.com/read.php?2,27108

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

Quite a history for this box, it wasn't easy to get here as I can see.

You are right, UART booting isn't absolutely necessary as it can work without that. And the hardware of this box is quite old, so maybe very few will benefit from this work.

However, you can count on me (even if I ugrade when I need a better hardware, I will keep like the NSA310S)

cyraxxx,

> You are right, UART booting isn't absolutely
> necessary as it can work without that. And the
> hardware of this box is quite old, so maybe very
> few will benefit from this work.

UART booting for at least one of these Armada boxes is quite important. I have not built new u-boot for these Armada boxes (they all have old Marvell u-boot) because I don't have a box that can be booted with UART consistently the way I want. That was why I spent a lot of time with this box.

But I've moved on to use another Armada box (Thecus N2350) to build new Armada u-boot. Building u-boot is just something for rainy day. No urgency.

>
> However, you can count on me (even if I ugrade
> when I need a better hardware, I will keep like
> the NSA310S)

The NSA310S is all done. Everything we need, I already got it to work. But thanks for the offer!

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



Edited 1 time(s). Last edit at 07/10/2020 04:29PM by bodhi.

Understood :)

Let me know if you need some testing, I got notified at every post of this topic.

Hi cyraxxx,

Since you are running the latest kernel on this box, can you confirm that you are runnig normally with Gbit network speed and have no error?

https://forum.doozan.com/read.php?2,106239,106249#msg-106249

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

Hi,

At least I had to install my previously bought 1 Gbit switch :D Until now I used an old one as 100 Mbit was enough for me. But I have 5.6.9 as I left that on the permanent system (based on changelog I decided there is no reason to upgrade 5.6.9->5.7.6, but I can if you want).

The relevant dmesg:
[ 0.000000] Linux version 5.6.9-mvebu-tld-1 (root@tldDebianVM) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #1.0 SMP PREEMPT Sat May 2 20:48:16 PDT 2020
[ 45.791220] mvneta f1070000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx (previous switch)
[82929.360086] mvneta f1070000.ethernet eth0: Link is Down
[82933.519517] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx (Gbit switch)

It remained at 1 Gbps connection after 30 minutes.

Quick measures:
copy from nas on lan (samba, 4gb file): 72-75 MB/s (576-600 Mbps)
copy to nas on lan (samba, 2gb file): 38-41 MB/s (304-328 Mbps)
speedtest: 290 Mbps (but I have a 300 Mbps internet, so not suprising)

If I will face an error related to the network connection, I will update this post.

Update: installed the 5.7.6 kernel, the results are the same, no problems so far. It drops the link when changes the MAC, but that's all.

[ 33.634008] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 33.642774] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 35.073418] v5.0-sata1: supplied by pwr_en_sata1
[ 35.078815] v12.0-sata1: supplied by pwr_en_sata1
[ 35.086237] v5.0-sata0: disabling
[ 35.090444] v12.0-sata0: disabling
[ 35.094917] v5.0-sata1: disabling
[ 35.098952] v12.0-sata1: disabling
[ 41.855478] NFSD: Using UMH upcall client tracking operations.
[ 41.862053] NFSD: starting 90-second grace period (net f0000039)
[ 42.773074] Setting Persistent MAC address to 98:0D:67:4D:4E:B5
[ 44.597103] mvneta f1070000.ethernet eth0: Link is Down
[ 45.744698] mvneta f1070000.ethernet eth0: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510] (irq=POLL)
[ 45.755323] mvneta f1070000.ethernet eth0: configuring for phy/rgmii-id link mode
[ 48.918812] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 48.927971] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready


Best regards



Edited 1 time(s). Last edit at 07/17/2020 04:17AM by cyraxxx.

Thanks cyraxxx!

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