From: Alexander Dahl <ada@thorsis.com>
To: linux-mtd@lists.infradead.org
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
Richard Weinberger <richard@nod.at>
Subject: mtd: nand: atmel: probe of Spansion S34ML02G1 fails
Date: Tue, 25 Jul 2017 11:26:33 +0200 [thread overview]
Message-ID: <5326598.QgYTQxcFMR@ada> (raw)
Hello,
when testing the recent v4.13-rc2 on our at91sam9g20 based platform I
discovered one of the NAND flash chips we use can not be setup correctly
anymore. I guess this may be due to the reworked atmel nand driver after
v4.9, but it may be another problem.
The board layout is similar to the at91sam9g20ek for the NAND flash part
and we're using different flash chips. With an hynix HY27UF082G2B
everything works, the console output on boot is like this:
nand: Could not find valid ONFI parameter page; aborting
nand: device found, Manufacturer ID: 0xad, Chip ID: 0xda
nand: Hynix NAND 256MiB 3,3V 8-bit
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
The same board with another pin compatible flash chip, the Spansion
S34ML02G100TF100 however fails. I added some debug print statements to a
otherwise clean 4.13-rc2 kernel and get this:
nand: device found, Manufacturer ID: 0x01, Chip ID: 0xda
nand: AMD/Spansion S34ML02G1
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
nand: onfi_version: 10, onfi_params.opt_cmd: 0x001B
nand: chip->onfi_set_features() failed: -22
nand: nand_setup_data_interface() failed: -22
atmel-nand-controller 10000000.ebi:nand-controller: nand_scan_ident()
failed: -22
atmel-nand-controller: probe of 10000000.ebi:nand-controller failed
with error -22
So in the ONFI parameter page of the flash chip the value for "optional
commands supported" in the features block is 0x001B which is exactly
what the datasheet says. This means this flash chip does not support
"Get Features" and "Set Features".
Now nand_onfi_set_features() correctly fails, because the nand chip can
not set features. It's called in nand_setup_data_interface() in
nand_base.c which fails itself because of the return value of the failed
set features call and so the whole chain of fails starts.
The nand chip actually works fine in U-Boot, and with kernels up to
v4.9.35, I didn't test v4.10, v4.11, but IIRC the board booted from nand
flash with v4.12.
Can anyone help me to fix this?
Greets
Alex
next reply other threads:[~2017-07-25 9:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 9:26 Alexander Dahl [this message]
2017-07-25 18:54 ` mtd: nand: atmel: probe of Spansion S34ML02G1 fails Boris Brezillon
2017-07-26 8:15 ` Alexander Dahl
2017-07-26 18:33 ` Boris Brezillon
2017-07-26 20:40 ` Alexander Dahl
2017-07-27 19:27 ` Boris Brezillon
2017-07-31 6:13 ` Alexander Dahl
2017-07-28 13:15 ` Alexander Dahl
2017-07-28 19:13 ` Boris Brezillon
2017-07-31 6:29 ` Alexander Dahl
2017-07-31 7:44 ` Boris Brezillon
2017-07-31 8:41 ` Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5326598.QgYTQxcFMR@ada \
--to=ada@thorsis.com \
--cc=boris.brezillon@free-electrons.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox