Restoring stock UBoot on Zyxel NSA320

[psychokiller]

Hi all,
I have tried to restore Zyxel NSA320 stock uboot and env using files and instructions from here https://archlinuxarm.org/forum/viewtopic.php?f=23&t=6532#p36346 but while writing to and I always get the following error:

$this->bbcode_second_pass_code('', '
nandwrite -oa /dev/mtd0 /mnt/nsa320_uboot.ndi
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000
libmtd: error!: MEMWRITE ioctl failed for eraseblock 7 (mtd0)
error 22 (Invalid argument)
nandwrite: error!: /dev/mtd0: MTD write failure
error 22 (Invalid argument)
nandwrite: error!: Data was only partially written due to error
error 22 (Invalid argument)
')
I am using nandwrite from a Debian Buster installation: does anyone have any idea what I am doing wrong?
Thanx for your help.
Paolo

[summers]

Some times the speed of the flash doesn't work with the modern kernel. If so trick is to down clock in the device tree. I'll look up the setting later, but you can find it via Google on this site ... Also check you have the right nand device name, this also changed a few years ago, and if you have the wrong on mtd0 isn't writeable ...

[psychokiller]

Hi summers,
I suppose you are referring to the process described in this post https://archlinuxarm.org/forum/viewtopic.php?f=15&t=12732#p58288 that is:

• 1) decompile proper device tree from .dtb to .dts with dtc
• 2) modify chip-delay = <0x23>; to chip-delay = <0x28>;
• 3) recompile to binary .dtb and generate a new kernel uImage with dtb embedded (since I don't have a UBoot capable to use the .dtb) like described here https://forum.doozan.com/read.php?2,12096 at step 4 of the update of 25 Aug 2019
• 4) boot and try to nandwrite again

I will give a try to the process: the fun part is that if it fails I have to go through kwboot and fatload/nandwrite the old UBoot every time, then go through step 1/4 again.
Any suggestion for the chip-delay value to try?
Thanx, Paolo.

[summers]

If you have a modern uboot, you can have it modify the device tree, which is far easier than recompiling the device tree. I'll give the command when I get home. First though check if you are using the right driver for modern kernel.

[summers]

OK on my NSA325 - which is similar to the NSA320 in /boot/uEnv.txt I have:
$this->bbcode_second_pass_code('', 'root=PARTUUID=94a2dc27-01
mtdparts=mtdparts=orion_nand:0xC0000(uboot),0x40000(uboot_env),0x80000(old_uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)
loadfdt=echo loading ${fdtdir}/${fdtfile} ...; load ${devtype} ${bootpart} ${fdtaddr} ${fdtdir}/${fdtfile}; fdt addr ${fdtaddr}; fdt set /mbus@f1000000/nand@12f chip-delay <45>')
First thing note is mtdpart changes the chipset name (and does my flash layout). You can check this via $this->bbcode_second_pass_code('', 'cat /proc/cmdline') where you want something like:
$this->bbcode_second_pass_code('', 'console=ttyS0,115200 mtdparts=orion_nand:0xC0000(uboot),0x40000(uboot_env),0x80000(old_uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=PARTUUID=94a2dc27-01 rw rootwait')
And the important bit is $this->bbcode_second_pass_quote('', 'o')rion_nand:

[psychokiller]

I finally managed to write to flash booting from the Arch Linux rescue system and
$this->bbcode_second_pass_code('', 'nandwrite -oa /dev/mtd0 nsa320_uboot.ndi')
finally gave no error.
I flashed both nsa320_uboot.ndi and nsa320_uboot_env.ndi, but when rebooted the NSA320 was bricked and original UBoot wasnt booting.
I can confirm that the driver used by the rescue system is
$this->bbcode_second_pass_code('', '(rescue)[root@alarm ~]# cat /proc/cmdline
console=ttyS0,115200 ubi.mtd=1 root=ubi0:rootfs ro rootfstype=ubifs rootwait mtdparts=orion_nand:1M(u-boot),-(rootfs)
')
and MTD partitions seems to be OK
$this->bbcode_second_pass_code('', '(rescue)[root@alarm ~]# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 07f00000 00020000 "rootfs"
')
I also downloaded nsa320_uboot.ndi again and checked md5 checksum again the previous download, both have the following checksum
$this->bbcode_second_pass_code('', '1c1562eda35054fc0c50bd363242566f')
So, maybe I am doing something wrong or the UBoot dump isn't good or for my revision of NSA320?
Quite puzzled....

[summers]

If bricked "kwboot" via the serial port may rescue.

Also via the serial port you can see what functionality (if any) the uboot has.

After writing, you can also check the flash, just by comparing the contents to what you flashed ...

[psychokiller]

Yes, of course I used kwboot to restore latest UBoot from the ALARM distribution.
I probably did not explain clearly what my problem is.

I tried to flash the stock NSA320 UBoot and env using the procedure described here https://archlinuxarm.org/forum/viewtopic.php?f=23&t=6532#p36346 with files uploaded by WarHeadSE.

Flashing with nandwrite works OK with no error when booting with ALARM Rescue with ALARM UBoot, but once nandwrite finishes, I reboot and the stock UBoot does not start, NSA320 is bricked with all LEDs on, no output on serial port.

So I have to restore ALARM UBoot with kwboot.

So I am asking myself if I am flashing in a wrong way or the UBoot and env files uploaded by WarHeadSE here http://os.archlinuxarm.org/os/nsa3x0/ are not good anymore?

Quite puzzled still...

[summers]

Well WESE does give the warning it may not work.

Assuming you just flashed uboot - your flash should hopefully still have the original OS still on it. So you should be able to direct uboot to boot it, and save that to the env variables. Don't know if you took a copy of your original flash layout? Think on my NSA325 it was:

$this->bbcode_second_pass_code('', '0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)')

so you can probably point fw_printenv to the old env variables - and read those for what to set to boot from flash. You may then need to translate into the new uboot language ...

[psychokiller]

Yes, seen the warning, but it seemed to work for another user, so I hoped it would have worked for me.
And no, I have ALARM rescue now, not the original OS, think that is gone completely.
Thank for your help.
Will think about it and will decide what to do with the box...