4.4.97-1-ARCH wrong NAND chip timing in the DTS? NSA310 NAS

[summers]

Well done! We are almost there. now you are in linux, and the flash looks good.

I seem to be on this kernel: https://archlinuxarm.org/packages/arm/linux-armv5 so I'm guessing it just hasn't yet reached your mirror. Going down a version won't be a problem.

fw_printenv is probably not working due to incorrect settings in /etc/fw_env.config you'll need that pointing to where you old boot keeps its env variables, think its at 0x100000, which may be in /dev/mtd1 and not /dev/mdt0. I think all you'll need from the current uboot is the ethernet mac address - and that you have posted above.

Now as for the update. Yes as you have several things that need doing, you will need to do them all.
1) Update to a new dt kernel package
2) make sure the old package is gone
3) update to the latest uboot
4) Make the chip timing changes, either in /boot/uEnv.txt or in uboot env variables.
5) probably make sure your mac address is right in the updated env variables
6) Also get the PARTUUID of your root disk and set in /boot/uEnv.txt

Somewhere on here is the commands to type, let me see if I can find them.

Ok seems to be:
$this->bbcode_second_pass_code('', 'pacman -Syu linux-kirkwood-dt linux-kirkwood-dt-headers uboot-nsa310')
You may find some stuff doesn't install - as your md partitions aren't what was expected. if that happens *DO NOT REBOOT* - you'll need to work out what should have been done, and do it by hand.

You may have a problem with your /boot is a separate partition, e.g. you'll need to check where uboot looks for the kernel etc, e.g. does it need to be in a /bot directory, or can it be in / (when /boot is a partition).

Basically check all this before a rebooot, only when 110% sure should you reboot.

Anyway 90% there now, so I'm off to repair my racing bike ....

$this->bbcode_second_pass_quote('', 'W')ell done!

[summers]

Well from the install script: https://archlinuxarm.org/packages/arm/uboot-nsa310/files/uboot-nsa310.install all we need from the old uboot env variables are the mac address. You have this already as you printed the env variables.
$this->bbcode_second_pass_code('', 'ethaddr=00:19:CB:00:51:81')
Assuming that your /dev/mtd0 is 0x100000 long, then new uboot will put its env variables in there at 0xc0000. So after uboot update, thats what you'll need to set /etc/fw_env.config to.

In old uboot you probably need /etc/fw_env.config to be
$this->bbcode_second_pass_code('', '/dev/mtd1 0x0 0x20000 0x20000')
As /dev/mtd0 is already 0x100000 long, so the env variables @0x100000 are at 0x0 in /dev/mtd1 ...

Now when you look at new env variables: https://archlinuxarm.org/packages/arm/uboot-nsa310/files/uboot-nsa320.txt you can see it looks for files under the ${bootdir} which by default is /boot. This is taken in reference to the top of the partition. So if you have a separate boot partition (which is what old arm did) then you have to change ${bootdir} to point to the top. What most of us do though, is as new uboot can access ext4 files, is that we umount /boot; and remove it from /etc/fstab, and the create the boot files under /boot on the root partition. Then uboot finds it fine.

I think when you do updates to dt kernel etc, it says it has to remove the old kernel, as its incompatible. But worth checking that you only end up with the new kernel and uboot.

/boot/uEnv.txt you want looking something like:
$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>')
The partuuid you can get from
$this->bbcode_second_pass_code('', 'ls -l /dev/disk/by-partuuid/')
mtdparts depends on how you want to sent up your flash. I kept the original firmware that came with the device, so kept the above. ArmArch tries to push you to putting a recovery system on the flash. Then I think it has one partition for uboot (0x100000) and the rest for the recovery partition. So depending on what you want, will be what you put here.

The last line you know already - its to reset the chip delay in the device tree.

Finally worth saying, is if all this works. Do email the linuk kernel maintainer that does the kirkwood device tree, and let them know you have to change the chip timing. If this is a problem than many people have, then they should change the timing in the original device tree ...

Oh yes, if you go with bodhi uboot, hist latest is a 2017 version. So I'm not sure if on that he moved onto uboot scripting. If he did, then all the above would change, probably get closer to other arm arch systems. Anyway it would be more work ...

[arti74]

Thank you summers.
This fw_env.config file works. $this->bbcode_second_pass_code('', '/dev/mtd1 0x0 0x20000 0x20000')
Now:
$this->bbcode_second_pass_code('', '[rtorrent@alarm ~]$ sudo fw_printenv
[sudo] password for rtorrent:
bootdelay=2
baudrate=115200
loads_echo=0
eth1addr=00:19:CB:00:51:82
ipaddr=10.4.50.165
serverip=10.4.50.5
rootpath=/mnt/ARM_FS/
netmask=255.255.255.0
nandEcc=1bit
MODEL_ID=A203
PRODUCT_NAME=NSA-310
FEATURE_BIT=00
CONTRY_TYPE=FF
VENDOR_NAME=ZyXEL Communications Corp.
run_diag=yes
console=100000
=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x7f00000@0x100000(root)
CASset=min
ethprime=egiga1
bootargs_root=root=/dev/nfs rw
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
ethmtu=1500
eth1mtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
yuk_ethaddr=00:00:00:EE:51:81
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
arcNumber=4402
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
bootcmd_linux=setenv=bootargs $(bootargs_linux); ide reset; ext2load ide 0:1 $(loadaddr) /uImage; bootm $(loadaddr)
MALLOC_len=3
bootcmd=run bootcmd_linux
bootargs=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
stdin=serial
stdout=serial
stderr=serial
nandEnvBase=100000
mainlineLinux=yes
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
disaMvPnp=no
hddPowerCtrl=no
enaAutoRecovery=yes
kernel_addr=0xc80000
pcieTune=no
ethact=egiga1
ethaddr=CC:5D:4E:C9:F5:4A
')
At the bottom is the correct MAC address I set from UART.

So the /boot has to be on the root partition? There should be a way to set the correct path somewhere.
And regarding this mtdparts part in the uEnv.txt file - should it be there, or that what I have in printenv is enough?
The chip-delay part has to be exactly the same as you have in your file? As I remember the value for nsa310 was 40 not 45, I don't know the rest.

$this->bbcode_second_pass_quote('', 'D')o email the linuk kernel maintainer that does the kirkwood device tree, and let them know you have to change the chip timing

[summers]

When you flash the new uboot, all the old environment variables go away, well they can sill be accessed at 0x0@mtd1, but new uboot uses 0xc0000@mtd0. So you have to create things anew, most comes from https://archlinuxarm.org/packages/arm/uboot-nsa310/files/uboot-nsa310.txt so all you need extra is the mac address. then set root, and think about mtd partitions.

But if you look at the above, you'll see it does things differently than the stock uboot. Its one of the hassles I have with the upgrade path to new uboot - I don't think its explained anywhere quite whats different and why. Its the reason i came up with the script posted near the begging of the thread (or was it your other thread?) - my script tried to work with both the old stock set up, as well as new set up. The rescue system came along later, for even more ways to change the flash.

if you type
$this->bbcode_second_pass_code('', 'mount')
You can see all mounted file systems. You need to see is /boot is listed there. Old arm arch used to have /dev/sda1 mounted as /boot IIRC.

If it is mounted, then do a step something like
$this->bbcode_second_pass_code('', 'sudo umount /boot
mkdir /tmp/boot
sudo mount /dev/sda1 /tmp/boot
cd /tmp/boot
tar cf - . | sudo ( cd /boot ; tar xf - )
cd
sudo umount /tmp/boot')
Then both sda1 and /boot will have the same files in, old uboot looks in the former, new uboot will look in the latter.

Now if you do this, you want to find out why it was mounted, it is probably set in /etc/fstab. So if you don't want to mount it in future - you'll need to remove that ...

So you want to set up /boot/uEnv.txt in the latter etc.

E.g. its worth understanding how the world changes when you do the upgrade, and checking everything *twice* that its right in the new set up.

$this->bbcode_second_pass_code('', '[rtorrent@alarm ~]$ mount
/dev/sda2 on / type ext4 (rw,relatime,stripe=8191,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=124220k,nr_inodes=31055,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /run/user/1003 type tmpfs (rw,nosuid,nodev,relatime,size=24880k,mode=700,uid=1003,gid=1003)
')
$this->bbcode_second_pass_quote('', 'I')f it is mounted, then do a step something like

[summers]

That /boot isn't mounted is good, it means you can install new uboot (and linux) without worrying about it. That will populate /boot on sda2.

[As a sideline, you almost certainly have sda1 partition that isn't mounted. It is formatted ext2 and contains the boot files. With stock this is needed, and uboot doesn't understand ext4 but does understand ext2. After the update you won't need the /dev/sda1 partition, I removed it on my nsa325.]

mtd partitions are kind of magic to many of us! What you need to know is currently it contains the operating system that the nsa310 came with. It has a couple of copies of a kernel, and some root file systems, and some other information we know not what for (or I don't anyway). You'll need to decide if you want to keep this or not - its your choice. If you don't want to keep it, then the default mtd partitions is a 0x100000 partition for uboot, and then rest as one big partition.

On that link, it says: $this->bbcode_second_pass_quote('', 'N')ote: for boxes such as Pogo V4 and Zyxel NSA3xx, the mtd partition definition are kept the same as stock definition, therefore is different from the one above.

[arti74]

Thanks for reply.
So I won't be worry about my sda1, even can delete it later. Should I worry about those mtd or can I leave it as it is?
Now I see in the repo the new linux-kirkwood-dt 4.16.7-1 kernel, so I'm ready to go for it all. I hope that my uEnv.txt file that I'll prepare will be good, if not I can always edit it...

$this->bbcode_second_pass_code('', 'fdt set /mbus@f1000000/nand@12f chip-delay <45>')
Will the above part be correct for my nsa310? Shouldn't it be specified already in the proper .dtb file? - in my case kirkwood-nsa310.dtb

EDIT:
I could't resist and installed kernel, but during uboot install I got this:
$this->bbcode_second_pass_code('', 'Warning: Bad CRC, using default environment
flash_erase: error!: /dev/mtd0
error 13 (Permission denied)
flash_erase: error!: /dev/mtd0
error 13 (Permission denied)
nandwrite: error!: /dev/mtd0
error 13 (Permission denied)
nandwrite: error!: /dev/mtd0
error 13 (Permission denied)
Warning: Bad CRC, using default environment
Can't open /dev/mtd0: Permission denied
Error: can't write fw_env to flash
error: command failed to execute correctly')
My /etc/fw_env.config settings looks like this
$this->bbcode_second_pass_code('', '/dev/mtd0 0xc0000 0x20000 0x20000')
even though I changed it for:
$this->bbcode_second_pass_code('', '/dev/mtd1 0x0 0x20000 0x20000')
During uboot install it changes for the first config...
Maybe should I first reboot after reinstalling the kernel? Or better not..
EDIT:
I just made the restart and everything is like it was before, no nand errors, but of course no u-boot update..

[summers]

Lets go over the various parts.

In the dtbs I send you, I set chip to <40>. When I was testing other methods on my end, I changed the numbers slightly, so I could see which ones took effect. So looks like <40> is OK with you, as it didn't have errors when you booted that.

you can check with $this->bbcode_second_pass_code('', 'od -tu1 /proc/device-tree/mbus\@f1000000/nand\@12f/chip-delay')

Choice on mtd is up to you:
1) You want to keep the original set up, in case you want to go back to it. Then with my settings it will stay in flash - and you'll know this when you look at the set up
2) You want to keep the original set up, take a copy of /dev/mtd*, then do what you want
3) You don't care for the original set up, you again do what you want (but don't take a backup).

Now what to do with your flash, after you uboot you could install the rescue system, its on https://archlinuxarm.org/forum/viewtopic.php?f=30&t=8383

When installing new uboot it follows: https://archlinuxarm.org/packages/arm/uboot-nsa310/files/uboot-nsa310.install

First off you can see why $this->bbcode_second_pass_code('', 'mac=$(fw_printenv | grep ethaddr | cut -d= -f2)') failed, as there is code before that says $this->bbcode_second_pass_code('', 'echo '/dev/mtd0 0xc0000 0x20000 0x20000' > /etc/fw_env.config'), but we know your env are at 0x100000=0x0@mtd1. So the code is looking in the wrong place. One of the reasons I had my script ...

SO you can see that /dev/mtd0 needs to be be at least 0x100000 long to fit both uboot+env in. So you don't want to change this with say $this->bbcode_second_pass_code('', '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)') until after you have done the update.

What it looks like, was you couldn't write to /dev/mtd0. WHat does $this->bbcode_second_pass_code('', 'mtdinfo /dev/mtd0') say?

No as you can see how the update is done, you can try each bit, and see what goes wrong. That will give an idea of what the problem is.

As you have started update, probably best not to reboot, until you have solved problems.

[arti74]

Thank you for your answer.

$this->bbcode_second_pass_code('', 'rtorrent@alarm ~]$ od -tu1 /proc/device-tree/mbus\@f1000000/nand\@12f/chip-delay
0000000 0 0 0 40
0000004')

$this->bbcode_second_pass_code('', '[rtorrent@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
')
Not writable device :/