Can I use linux-kirkwood-dt on NSA320 ?

[boteium]

So, I need to boot into Zyxel stock firmware, enable ssh server, login and flash uboot using the command in .INSTALL ?

[moonman]

viewtopic.php?f=53&t=8857&start=50#p48437

Yup. Obviously DO change every mention of nsa325 to nsa320.
Package is here: http://ca.mirror.archlinuxarm.org/arm/a ... pkg.tar.xz

[summers]

On my NSA325 this is approximatly what I had to do. Should be similar on the NSA320, so read thgrough - and it should give the guidance you need.

$this->bbcode_second_pass_code('', '
#!/bin/bash

if { mtdinfo /dev/mtd0 | egrep "Device is writable:.*false" > /dev/null; } then
# probably the nand driver name is set wrong
{
if [ `cat /sys/devices/virtual/mtd/mtd1/offset` -eq 1048576 ]; then
# almost certainly in the stock mtd set up so uboot_env is in /dev/mtd1
echo '/dev/mtd1 0x0 0x20000 0x20000' > /etc/fw_env.config
# and the mtd driver is orion_nand
fw_setenv bootargs_linux 'console=ttyS0,115200 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) root=/dev/sda2 rw rootwait loglevel=8'
# and now we need to reboot
reboot
;
else
echo I dont know where to find the uboot env variables
;
fi
}
fi

if { mtdinfo /dev/mtd0 | egrep "Device is writable:.*true" > /dev/null ; } then
{
# we are good to write the new uboot. first grab the current mac address
# from the old uboot env variables
mac=$(fw_printenv | sed -n 's/^ethaddr=\(.*\)/\1/p')
# flash U-Boot
flash_erase /dev/mtd0 0 4
flash_erase /dev/mtd0 0xc0000 1
nandwrite /dev/mtd0 /boot/uboot-nsa325.kwb
nandwrite -s 0xc0000 /dev/mtd0 /boot/uboot-nsa325.env
# now we can update the uboot env varible area to the new area
echo '/dev/mtd0 0xc0000 0x20000 0x20000' > /etc/fw_env.config
# and set the mad address
fw_setenv ethaddr ${mac}

# is boot mounted
boot=$(mount | sed -n 's/^\([^ ]*\).* \/boot .*/\1/p')
if [ ${boot} ] ; then

# /boot is a mounted partition
# we want to set this up as part of root with new uboot (e.g. a directory)
umount /boot
mkdir /tmp/boot
mount ${boot} /tmp/boot
# copy the files from the old boot partion into the new boot directory
(cd /tmp/boot ; tar cf - . ) | ( cd /boot ; tar xf - )
sync
umount /tmp/boot


# and remove /boot from the fstab
sed '/^.*\/boot.*$/d' < /etc/fstab > /etc/fstab.new
mv /etc/fstab.new /etc/fstab
;
fi

# make sure right root is passed in uboot (should this be written to the permanent env variables?)
root=`mount | sed -n 's/^\([^ ]*\).* \/ .*/\1/p'`
echo root=${root} > /boot/uEnv.txt

}
fi
')

[summers]

OK, have a few more minutes now to talk over the issues.

During the evolution of the linux kernel, at some stage (not clear when) the name of the nand driver was changed. It changed from nand_mtd to orion_nand. Now this name is needed to be passed to the kernel on boot, and alas the install script for zylnx (http://de7.mirror.archlinuxarm.org/os/nsa3x0/) never got updated. Now this line is passed to the kernel in uboot, and this doesn't get updated (or rather the enviroment variables don't get updated after install). So the wrong line gets passed by uboot to the kernel.

So first thing is to correct the parameter passed to the kernel in uboot. This you do be rewriting the uboot enviroement variables, usually from inside linux. This gives the next problem, often the adress in flash where the enviroement variables are held is set wrong in /etc/fw_env.config. So you need to correct those first. You can check this works with $this->bbcode_second_pass_code('', 'sudo fw_printenv'). Once this is corrected, you can update the bootargs_linux variable to the correct value for modern kernels.

Doing this means that after a reboot you get read/write access to the flash, before with the wrong name, you just get read access.

Next issue is that uboot likes the mac address of the ethernet set correctly - and you are going to loose this when you rewrite uboot. So you need to take a copy of this.

Then you can rewrite the flash with the new uboot and its enviroement varaibles.

Now new uboot, has a different memory map than the stock uboot. So you need to update /etc/fw_env.config to the new value. After doing this you can rewrite the mac address to the uboot env variables, to the value you saved before.

Next its best if you clean up any /boot mounts you have. Stock uboot only could access ext2, so where users wanted root to be ext4, boot needed to be a seperate partition. Now the new updated uboot can read ext4 - so it makes sense to undo any changes you have made to /boot - and have that directory as part of the main filesystem.

Finally you need to make sure that the uboot knows where to find the root filesystem, am not sure the logic in the script I posted yesterday is infalible - so I'd check this carefully.

After all this, you can reboot to the new uboot and dt based kernel.

Wish it wasn't this complex. But my conclusion is you can't escape from most of this. I can't see how switching to stock install would work, as e.g. there are still old values on http://de7.mirror.archlinuxarm.org/os/nsa3x0/ - and you can never update with those. Ideally this would be cleaned up at some stage, but there doesn't seem much entusiasm behind this.

Hope this helps.

[boteium]

@summers :
Thanks for the elaborate explanation. I will flash it once I get back home.

[WarheadsSE]

The reason, originally, for not updating them is the ability to revert to stock quickly.

Otherwise, you'd have to revert more than one part of the environment to get it all to work cleanly.

[summers]

I'm confused, in usb_key_func.sh.2 if the update:

$this->bbcode_second_pass_code('', 'fw_setenv bootargs_linux 'console=ttyS0,115200 mtdparts=orion_nand:0x100000(uboot)
,0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kern
el_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=/dev/sda2 rw
rootwait loglevel=8'')

was made, you could keep:

$this->bbcode_second_pass_code('', 'fw_setenv bootargs_stock 'console=ttyS0,115200 mtdparts=nand_mtd:0x100000(uboot)
,0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kern
el_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=/dev/nfs rw
init=/init'')

And that should revert to stock without any problems? Am I missing something?

[WarheadsSE]

Quite possibly not.

[boteium]

well, it doesn't boot now....
I guess i still miss something in fw_env
God, It would take several days to get a usb serial cable.

[summers]

If flashing the new uboot and env variables worked, then its probably the root setting. New uboot (and env) can read additional enviroment variables from: /boot/uEnv.txt. So in my case I solved the problem, by popping the HDD, and plugging it in another machine. Then writing to the /boot/uEnv.txt file:
$this->bbcode_second_pass_code('', 'root=PARTUUID=94a2dc27-01')

You can get the PARTUUID by using blkid and get the value for root partition (/) which has /boot inside it.

Anyway that was enough for me to get the NAS too boot.

To my mind this is why we should write a robust script that updates everything, checking very carefully as it goes. As if it fails at some stage the machine tends to brick itself, and its a hassle to get it back. What updating the uboot is equivalent to on a PC is reflashing the bios - and I always find that scary.