[LEDE-DEV] [PATCHv2 3/4] kernel/4.4: add generic spi-nand framework

[Christian Lamparter]

On Monday, September 4, 2017 1:48:38 PM CEST Weijie Gao wrote:
> Yes. If I search "spi-nand linux" in Google, Micron's framework is the
> first result.
> However, Micron's patches are based on higher version of kernel, which
> require lots of modifications to port to linux-4.4.
> I choose the framework from LEDE's
> target/linux/pistachio/patches-4.9/, which requires only few changes.

Yes exactly this is my concern: all the porting of of out-of-tree patches.
linux-4.4 has only about five to six more month left before the patches
will run out:
<https://www.kernel.org/category/releases.html> (Projected EOL: Feb, 2018).
So question is, what will ar71xx do in six month? Will it be updated to 4.9?
Or will it be ported to the upcoming 4.14? (I don't know?) Would you be 
willing to stick around and be prepared to revisit the patch in this case too?

> I've read nearly all datasheets from GigaDevice, Micron, Winbond,
> Macronix, and other manufacturers. I found that their chips are not
> full compatiable with each other.
> For example, the ECC status bits definition. GigaDevice uses one
> status to indicate the unrecoverable bits while Winbond uses two
> statuses to indicate that.

> And stacked die selection command is different between Micron and
> Winbond. And Mircon's chip has its own plane selection bit.
> 
> Even chips of the same manufacturer, the page size/OOB size and layout
> can be different. You can see differences of GigaDevice's chips in
> this patch.
> 
> So, the mt29f_spinand is not enough, it's designed only for
> Micron's chips.
A micron engineer put it like this:
<http://lists.infradead.org/pipermail/linux-mtd/2014-November/056531.html>

" As far as I've seen from the datasheets I have available (SPI NAND
GigaDevice 1Gb/2Gb/4Gb, Micron 1Gb/2Gb/4Gb), the command sequencing
is the same for read/write/erase operations (read: enable ECC, read to cache,
wait, read from cache, check for errors, disable ECC; write: enable ECC,
write enable, program load, program execute, wait, verify, disable ECC;
erase: write enable, erase block, verify).

Regarding the stream of bytes for each command, the problematic
commands are the read from cache ones (read, fast read, read x2,
read x4, read dual read quad) that have different command format
(additional dummy bytes, a plane select bit to be set).
Other differences are in the structure of the protection and status registers
(some of them use more ECC and protection bits according to the size
of the chip). Also, each has a different ECC layout "

The funny thing is, that a micron engineer made a patch back in the day
that had support for both the MT29F and your GD5F with
<http://lkml.iu.edu/hypermail/linux/kernel/1501.0/03747.html>
>From the look of it, it seems easy to support the GD5F that way...

So much so, that "this unification habbit" was picked up by imgtec
for the pistachio!

Just look at this pull request from an ImgTec engineer titled:
"Add Imagination's Pistachio SoC and (Ci40) Marduk platform support" for
openwrt project:
<https://github.com/openwrt/openwrt/pull/201/files#diff-b70d21c394349496f5f6a7e6b5a05a7c>

Look at the target/linux/pistachio/patches-4.4/0001-mtd-nand-Introduce-SPI-NAND-framework.patch
commit message:

"5. mtd: spi-nand: Support common SPI NAND devices
This commit uses the recently introduced SPI NAND framework to support
Micron MT29F and Gigadevice GD5F serial NAND devices. These two families
of devices are fairly similar and so they are supported with only minimal
differences."

> The framework I chose from
> <https://github.com/lede-project/source/tree/master/target/linux/pistachio/patches-4.9/413-mtd-Introduce-SPI-NAND-framework.patch>
> <https://github.com/lede-project/source/tree/master/target/linux/pistachio/patches-4.9/414-mtd-spi-nand-Support-Gigadevice-GD5F.patch>
> has two layers, one for generic nand operation and one for
> manufacturer-specific operations, such as the ecc status check.
> 
> I think this is a good practice.
Depends on how ar71xx will play out. For now, assume let's assume that
ar71xx is updated to 4.9. Then these patches would have to be moved to
either ar71xx's kernel patch directory: target/linux/ar71xx/patches-4.9
Or someone would have to *move* the existing 4.9 version out of 
target/linux/pistachio/patches-4.9 and into target/linux/generic/patches-4.9.
(Otherwise, quilt will complain because of the duplicated patches).

Regards,
Christian