NSA320: how to manually flash UBoot 2016.09?

[psychokiller]

While trying to flash UBoot 2016.09 on a NSA320 (and having already experienced the package install problems on a NSA325) I tried following the instructions here https://archlinuxarm.org/forum/viewtopic.php?f=53&t=8857&start=50#p48437.

So i booted a freshly installed ALARM from first sata hdd, installed uboot-tools, mtdutils and wget to download the uboot-nsa320 package. I unxz'd and untar'd the package and tried to issue a flash_erase command, but I got precisely the same error as with the installation using pacman -S uboot-nsa320:
$this->bbcode_second_pass_code('', '
flash_erase: error!: /dev/mtd0
error 13 (Permission denied)
')
So I tried removing the sata drive and boot to stock, just to realize that in stock flash_erase is missing...

What point am I missing? How can I manually flash the UBoot 2016.09 from stock linux or ALARM? Or do I have to flash it from UBoot using fatload and nand.write.e?

Thanx for any help.

[summers]

what does $this->bbcode_second_pass_code('', 'mtdinfo /dev/mtd0') say? If its that the device isn't writable, its usually becuase the wrong chip name has been given to the kernel for mtd devices. Newer kernels need to start: $this->bbcode_second_pass_code('', 'mtdparts=mtdparts=orion_nand:'), so the orion bit. This was the case on NSA325, so probably also on NSA320. You can try the change, safely I think, and see if it makes it writable ....

You can use $this->bbcode_second_pass_code('', 'dmesg | grep "Kernel command line"') to check

[psychokiller]

The commands you suggested shows this:
$this->bbcode_second_pass_code('', '
[root@alarm ~]# mtdinfo /dev/mtd0
mtd0
Name: uboot
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 8 (1048576 bytes, 1024.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 512 bytes
OOB size: 64 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: false
')

$this->bbcode_second_pass_code('', '
[root@alarm ~]# dmesg | grep "Kernel command line"
[ 0.000000] Kernel command line: 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/sda2 rw rootwait loglevel=8
')

So it seems it says mtdparts=nans_mtd instead of orion_nand: do I have to change the kernel command line in UBoot env or /boot/cmdline.txt in ALARM?

[summers]

So if your /boot has uEnv.txt (and uboot understands):

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

If your uboot doesn't yet do uEnv.txt then you have to change it via fw_setenv; so check fw_printenv for the mtdparts bits, and change nand_mdt to orion_nand

If that doesn't work, the machine I think should still boot - so you can change it back.

Orion is the name of the marvel nand driver btw, which is why the name change came about ....

I don't recall /boot/cmdline.txt - so don't recall if uboot reads that, but yes its the kernel command line you need to change ...

Oh yes, if you have access to the uart - you can just interrupt the boot, and just make the change for that single boot.

[psychokiller]

Thanx to summers!

I changed all the referencesto nand_mtd in the UBoot environment to orion_nand and I was finally able to do a flash_erase from ALARM.
I now have both NSA325 and NSA320 flashed with this UBoot version:
$this->bbcode_second_pass_code('', '
U-Boot 2016.09.01-1 (Oct 10 2016 - 23:15:39 -0600) Arch Linux ARM
Zyxel NSA320
gcc (GCC) 6.2.1 20160830
GNU ld (GNU Binutils) 2.27
')
And both are able to boot from a USB key with a single partition formatted with ext2 and http://os.archlinuxarm.org/os/ArchLinuxARM-kirkwood-latest.tar.gz unpacked on it.

If I format the fs with ext4 instead, UBoot does not load anything from it... Will open a new thread for that.

Paolo

[summers]

No problem. Things like this should be updated in the install script - the orion_nand has been the way its been in the kernel for many years, so the install script is just a hang over from days long past. This is a problem that has popped up quite a bit ...

So why do you have both a NSA320 and NSA325 box? Thats alot of NAS ....

Oh yes, also 2016 uboot can boot from ext4, so if you want to format the root file system as ext4 it will still work. 2016 uboot though doesn't do btrfs and the like (mine you come to that, neither does the default kernel - its needs a module for btrfs ...)

Oh you say ext4 doesn't work - odd its what I have:
$this->bbcode_second_pass_code('', 'cat /proc/mounts
...
/dev/sda1 / ext4 rw,noatime 0 0
...
')

$this->bbcode_second_pass_quote('', 's')ummers wrote:
So why do you have both a NSA320 and NSA325 box? Thats alot of NAS ....

[summers]

Sounds vaguely familiar. You could try making the file system with
$this->bbcode_second_pass_code('', 'mkfs.ext4 -O ^metadata_csum,^64bit /dev/sdb1')
Where you change sdb into whatever your usb stick is. And in the partition table make sure its id is 83 (Linux).

[psychokiller]

I googled the error message regarding the unsupported feature related to 64 bit something in ext4 and found this thread https://archlinuxarm.org/forum/viewtopic.php?f=53&t=12572.

Will try to prepare the USB key again by disabling the 64 bit feature of ext4 in the mkfs.ext4 invocation and will keep this thread updated.

Hold on for now...

Paolo

[psychokiller]

I recreated the ext4 file system with the ^metadata_csum,^64bit options and now UBoot 2016.09-1 loves it and boot it regularly.

$this->bbcode_second_pass_quote('', 's')ummers wrote:
..odd its what I have:
$this->bbcode_second_pass_code('', 'cat /proc/mounts
...
/dev/sda1 / ext4 rw,noatime 0 0
...')