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

[summers]

So now to find out why. What does $this->bbcode_second_pass_code('', 'dmesg | grep MTD') say? Its meant to say orion_nand, and if it doesn - then that causes the problem you have.

Actually thats what its mean to be on nsa325, what its meant to be on nsa310 I have no idea ...

Oh yes, /dev/mtd0 is the right length to write everything to it ...

[arti74]

This is the dmesg part:
$this->bbcode_second_pass_code('', '[ 1.091614] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1
[ 1.097996] nand: Samsung NAND 128MiB 3,3V 8-bit
[ 1.102909] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 1.110565] Scanning device for bad blocks
[ 1.181497] Bad eraseblock 631 at 0x000004ee0000
[ 1.227674] 9 ofpart partitions found on MTD device orion_nand
[ 1.233551] Creating 9 MTD partitions on "orion_nand":
[ 1.238717] 0x000000000000-0x000000100000 : "uboot"
[ 1.244020] 0x000000100000-0x000000180000 : "uboot_env"
[ 1.249631] 0x000000180000-0x000000200000 : "key_store"
[ 1.255209] 0x000000200000-0x000000280000 : "info"
[ 1.260367] 0x000000280000-0x000000c80000 : "etc"
[ 1.265453] 0x000000c80000-0x000001680000 : "kernel_1"
[ 1.271022] 0x000001680000-0x000004640000 : "rootfs1"
[ 1.276683] 0x000004640000-0x000005040000 : "kernel_2"
[ 1.282246] 0x000005040000-0x000008000000 : "rootfs2"')

[summers]

OK thats what I'd expect it to be. originally it was

from http://zyxel.nas-central.org/wiki/Some_information_from_slash_proc_(NSA-310)#cat_.2Fproc.2Fmtd "cat /proc/cmdline", that it used to be "nand_mtd:0" but under new linux it became orion_nand. Now if that name was wrong, the way we used to be able to tell was
$this->bbcode_second_pass_code('', 'mtdinfo /dev/mtd1')
was writable. So if mtd1 is writable but not mtd0, then its a sign we have something like this wrong. Alas though it doesn't say what we should have ...

Intersting on nsa325 it says
$this->bbcode_second_pass_code('', '[ 0.942064] nand: device found, Manufacturer ID: 0x92, Chip ID: 0xf1
[ 0.948527] nand: Eon NAND 128MiB 3,3V 8-bit
[ 0.952816] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64') so does sound like we have different flash ...

And https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood.dtsi suggest that *all* kirkwood devices have "marvell,orion-nand" - so its confusing.

[arti74]

Yes, the mtd1 is writable:
$this->bbcode_second_pass_code('', '[rtorrent@alarm ~]$ mtdinfo /dev/mtd1
mtd1
Name: uboot_env
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 4 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 512 bytes
OOB size: 64 bytes
Character device major/minor: 90:2
Bad blocks are allowed: true
Device is writable: true')
Thank you for everything @summers
You are the great help here.
Of course if you'll find something about the uboot update, please share it here.
For now I'm happy that I have the new kernel - thanks to you.
I'll see what Bodhi yet say. If I'll know something, then I'll write it here.

[summers]

yes that /dev/mtd1 is writable, is a good sign that the kernel is using the wrong driver. guess we could try nand_mtd, but we would be better finding someone with a nsa310, and find out what they used ...

Sorry, I'm not going to be much help here, as I have a nsa325 and know I need the orion driver for my machine.

Lets see what others say. Bodhi probably has a good idea ...

[arti74]

$this->bbcode_second_pass_quote('', 'B')odhi probably has a good idea ...

[summers]

Yes that would explain it, I though the command line took over dtb, but maybe not.

Alas will have to roll another uImage. I don't have time now. Can you do it, or want me to, maybe tomorrow, or friday ...

[arti74]

Thank you again - I'm not in rush, if you could make it... I would be very grateful. Please take your time. I took it too much from you already

[summers]

OK had half an hour spare this morning (have to go into work via the chemist, and chemist doesn't open until ~8:45!) so respan the nsa310 dts. New one on same link as before http://davidjohnsummers.uk/uImage_w_nsa310dtb.

What seems strange to me, is my nsa325 has the same bits in the dts. But for me mtd0 is writable. Now only difference for me, is that I'm using a recent uboot that does device trees. But how can that make a difference, it seems very unlikely that uboot goes into the device tree to change the nand set up unless explicitly told to.

So my guess on whats happening, is new boot passes the command line (including mdt info) via the device tree chosen node. I think linux must then take the chosen info to overide whats in the main device tree, and that includes the mtd details. Now of course your uboot doesn't write the chosen node - you you only get the default.

Anyway try the attached blob and see if it works, you can always check status first with mtdinfo.

[arti74]

Thank you very much for your effort, unfortunately after placing your file in the /boot directory (there was compressed zImage file instead of uImage - I moved this zImage to /home) and reboot, mtdinfo /dev/mtd0 still sais:
$this->bbcode_second_pass_code('', '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
')