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

[arti74]

Hello experts
I hope this is a good place for this question.
I have installed the Archlinux ARM for my Zyxel device from this package: https://archlinuxarm.org/platforms/armv5/zyxel-nsa320.
Dmesg shows nand errors on every single block of this chip and it's most likely due to a wrong chip timing in the DTS (I'm not so smart alone to deduce that, I found couple examples on the internet, with the same problem, although in Debian system).
I don't want to copy paste everything I wrote regarding this problem in other places - all the logs and details you'll find here https://forum.doozan.com/read.php?3,58144 and here https://archlinuxarm.org/forum/viewtopic.php?f=53&t=12717
What can I say... I need help with this, and I have no experience beside a basic usage of archlinux.

[summers]

Good call of you and bodhi, yes wrong timing would explain errors you get, so good idea to back off.

Two ways to do it (they are general, not arch specific):
1) recompile the device tree
2) have uboot modify the device tree

Now the problem with 1) is it needs to be redone every time the kernel is updated, as new device tree blobs come with every kernel. This means my preferred method is 2), I've done this on both BBB and Odroid c2, both of which needed at times device tree modification.

However, with your nand errors, it isn't each to access the flash from current kernel. Also IIRC my nsa325 has the old style uboot that has a function form of command execution, where a function is run, that calls other function, that call yet more functions, that eventuality set up what is needed to boot. Modern uboot tends to work from scripts - which are a tad easier to think about.

So what I'd suggest is first go modifying the device tree approach, see if that works. If we can get a working nand that way, then do the change in uboot instead.

Also if this corrects the problem, it should be flowed upstream to the maintainer - we would want the original deice tree for the nsa310 modififed with timings that work.

Anyway how to modify the device tree. Device tree blobs live in
$this->bbcode_second_pass_code('', '/boot/dtbs')
Find which one you are using. Then we'll need to change it to a source file, for that you'll need dtc:
$this->bbcode_second_pass_code('', 'pacman -Suy dtc')
I think works.
then
$this->bbcode_second_pass_code('', 'dtc -I dtb -O dts file.dtb')
That will expand to a dts file, you can edit it with a text editor - find the relevant terms, and modify.
After that change back into a blob, use the dtc command with input and output reversed.

After that should be able to reboot, you can check the change has happened in /proc/devicetree or is it /sys? Anyway there is a directory there that has the device tree in it.

How to do the uboot method, I'll need to look it up when I have more time. Its a bit complicated ...

sigh, and the timing is common to all nsa3xx devices https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi

And this thread gives the basics of how to do it the uboot method, which you'll have to adapt:
https://archlinuxarm.org/forum/viewtopic.php?f=67&t=12571

And reading your other thread, clearly a problem is that you can't boot a device tree kernel, without updating uboot ....

[arti74]

Great find summers! I just have one problem with it - in the dts file the corresponded value is:
$this->bbcode_second_pass_code('', 'chip-delay = <0x23>;')
I tried to change it for:
$this->bbcode_second_pass_code('', 'chip-delay = <40>;')
but resulted with error:
$this->bbcode_second_pass_code('', '/home/rtorrent/kirkwood-nsa310.dts:56.8-9 syntax error')
Maybe should it be:
$this->bbcode_second_pass_code('', 'chip-delay = <0x40>;')
? Just my guess...
I used this command to change dtb into dts:
$this->bbcode_second_pass_code('', 'sudo dtc -I dts -O dtb -o /home/rtorrent/kirkwood-nsa310.dts /boot/dtbs/kirkwood-nsa310.dtb')
and for reversal:
$this->bbcode_second_pass_code('', 'sudo dtc -I dtb -O dts -o /boot/dtbs/kirkwood-nsa310.dtb /home/rtorrent/kirkwood-nsa310.dts')
In the /boot/dtbs/ directory there are two similar files for my device: kirkwood-nsa310.dtb and kirkwood-nsa310a.dtb - I think I first try the first one, and if still "Bad eraseblock" errors I'll use the second file, with the "a" letter.

[EDIT]
I changed the <0x23> value for <0x28> in the .dts file but by converting for .dtb file I got:
$this->bbcode_second_pass_code('', '# dtc -I dtb -O dts -o /boot/dtbs/kirkwood-nsa310.dtb /home/rtorrent/kirkwood-nsa310.dts
FATAL ERROR: Blob has incorrect magic number
')
Maybe in the command .dtb ==> .dts I messed something up? I got these warnings:
$this->bbcode_second_pass_code('', '/home/rtorrent/kirkwood-nsa310.dts: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
/home/rtorrent/kirkwood-nsa310.dts: Warning (avoid_unnecessary_addr_size): unnecessary #address-cells/#size-cells without "ranges" or child "reg" property in /gpio_keys
')
I'm afraid I could accidentally change somehow the source /boot/dtbs/kirkwood-nsa310.dtb file during trying different conversion commands

[summers]

the "0x" just means in hex. So <40> is the same as <0x28> as you guess. I thought both of these should work, and on https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi it uses <35> so it should work.

Yes your commands look right, can't remember if I used to do ">" before the last file line.

I'm at home no, so can check on my nsa325, just a minute ....

OK what I did different was:
$this->bbcode_second_pass_code('', 'dtc -I dtb -O dts -o kirkwood-nsa310.dts kirkwood-nsa310.dtb')

So "-O" is the same as "-o", in the above dts ....

I changed it to 0x28.

Going in both directions I had the errors:

$this->bbcode_second_pass_code('', 'kirkwood-nsa310.dts: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
kirkwood-nsa310.dts: Warning (avoid_unnecessary_addr_size): unnecessary #address-cells/#size-cells without "ranges" or child "reg" property in /gpio_keys')

I've had warning like this in the past, I don't think they are a problem. Am not sure if this is becuase a problem in the main .dts, or if its due to going via a .dtb.

Note the errors are about memory and gpio_keys - so not something changed ...

Oh yes also tried <40> as well as <0x28> both worked and the result files are identical ....

If it helps to check you got it right, the result .dtb file should have "md5sum" "304d16771c45c4ccc901e0f527b93d57"

[arti74]

I messed up something for sure.
After this command:
$this->bbcode_second_pass_code('', 'sudo dtc -I dts -O dtb -o /home/rtorrent/kirkwood-nsa310.dts /boot/dtbs/kirkwood-nsa310.dtb')
I got:
$this->bbcode_second_pass_code('', 'Error: /boot/dtbs/kirkwood-nsa310.dtb:1.1-2 syntax error')
The first line of the .dtb file looks like:
$this->bbcode_second_pass_code('', '7ZyXEL NSA310
chosen=console=ttyS0,115200/ocp@f1000000/serial@12000
aliasesR/ocp@f1000000/gpio@10100X/ocp@f1000000/gpio@10140^/ocp@f1000000/i2c@11000
memorycmemoryo
cpus

cpu@0ccpuarvell,feroceonos

')
When I viewed this file previously, I believe it had mostly some unreadable signs..
What worse now in the /boot/dtbs/ directory I have only this kirkwood-nsa310.dtb file - what happened with the rest I don't have any idea.
I think I should somehow recover this all, but the source rootfs.tgz has not the dtbs folder inside the /boot/

$this->bbcode_second_pass_code('', 'md5sum /boot/dtbs/kirkwood-nsa310.dtb
56ac5436ac00a73c1a604947e37d3535')

[EDIT]
What comes to my mind now is to install fresh archlinux with 4.4.97-1-ARCH kernel again - on a different hard drive. If I could somehow add earlier the proper (or edited) .dtb file.. If not i'll try again the .dtb <==> .dts conversion.

Thanks @summers for your support

[summers]

Yes your problem is you did
$this->bbcode_second_pass_code('', '-O dtb -o /home/rtorrent/kirkwood-nsa310.dts')
That means write dtb output to the dts file, so you were writing to the wrong area. Usually do it like:
$this->bbcode_second_pass_code('', 'dtc -I dtb -O dts -o kirkwood-nsa310.dts kirkwood-nsa310.dtb')
or
$this->bbcode_second_pass_code('', 'dtc -I dtb -O dts kirkwood-nsa310.dtb > kirkwood-nsa310.dts')
And to convert the dts to a blob:
$this->bbcode_second_pass_code('', 'dtc -I dts -O dtb -o kirkwood-nsa310.dtb kirkwood-nsa310.dts')
You should be able to get the device tree back by reinstalling the kernel, I guess though not doing the last step as hard to boot device tree kernel. I'll also see if I can post the dts/dtb file when I get home (can't access from here).

Oh yes, how far did you get working out how to boot a device tree kernel with the old uboot? Does that need work?

Otherwise I'll work out how with new uboot you can modify the device tree.

[arti74]

Thanks for reply. I'm at work now and a bit busy.
Yesterday I tried to install archlinux to a new hdd - I bought 4tb WD40PURX, but I couldn't make it boot, I got some bad magic number error. I guess it may be that the old uboot I have don't support such big disks. I'll try today maybe with an old small one I have.
So I think my priority now is to update the uboot, or/and install the new -dt kernel - maybe I should try first with the previous installation - reinstall the kernel and if that recover my dtbs folder then the .dtb <=> .dts conversion? I could also try with fresh install on an another (small) drive.
I'm still 'fighting', thanks for being here to help.

[summers]

IIRC large HDD you need to format GPT, and then convert to hybrid. Then uboot can access the hybrid bit at the beginning of the disk, but link then can use GPT and access to whole HDD. Me, I've a 1TB disk in slot 1, and a 4TB in slot 2, and that boots fine. [4TB doesn't have a partition type! The whole disk is btrfs ...]

I managed to brick my nsa325 last night, I missed that it was quite at old uboot (2016) and that it had a different variable name for the device tree address; so when trying the uboot method to change the device tree - the machine bricked. uboot has been more robust in the past. So I'll have to crack open the case and attach a uart. So may be slow with new ideas, as may not get a chance to access before the weekend. [This means I've lost my farm of arm machines, most were hanging off the back of the NSA ...]

And thats interesting - the main uboot site has support for the nsa310 eg:

http://git.denx.de/?p=u-boot.git;a=blob;f=board/zyxel/nsa310s/nsa310s.c;h=aab33cfa2a2dd3fade10fb56587ffb0f84a6b403;hb=HEAD

But doesn't have nsa325 ..., so wonder where mine came from .... Also makes it a hassle to update to the latest ...

[arti74]

$this->bbcode_second_pass_quote('summers', 'c')onvert to hybrid

[summers]

OK, managed to access the UART - had to take out almost *every* screw to get inside. With access to the UART I could access uboot and reset the env variable. So if in arch you set the env variable via:

$this->bbcode_second_pass_code('', 'sudo fw_setenv loadfdt 'echo loading ${fdtdir}/${fdtfile} ...; load ${devtype} ${bootpart} ${fdtaddr} ${fdtdir}/${fdtfile} ; fdt addr ${fdtaddr} ; fdt set /mbus@f1000000/nand@12f chip-delay <40>'')

in U-Boot 2016.09.01-1, which is the latest uboot for the NSA325. On more modern uboot we would probably use a uboot script instead.

Then reboot, and:
$this->bbcode_second_pass_code('', 'od -tx1 /proc/device-tree/mbus\@f1000000/nand\@12f/chip-delay
0000000 00 00 00 28
0000004
')

So if you manage to flash a uboot that has fdt commands, then you can change the chip timing from uboot, which is easier than having to redo the device tree blob on every kernel update.

Anyway now I've the box open, and access to the uboot. Half tempted to update things. Certainly a quieter fan, and I've cleared all the dust out - so its had a clean.

Oh yes - also wonder if we could update loadfdt in /boot/uEnv.txt - looking at the boot sequence, looks like we could. That would be better, because if a change to uEnv.txt bricked the device, then could just pull the drive, mount elsewhere, and correct the fault ...