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

[Weijie Gao]

Yes, I have to admit operations of GigaDevice's chips are the same.
All the chips have the same read/write/erase command sequences.
Differences are plane selection bits (Micron), die selection
(Micron/Winbond), buffered read/continuous read (Winbond) and ECC
status bits.
These differences can be abstracted to different functions chosen by
the flash id. So this won't be a problem.

As for the patches, may be I can submit patches to both generic-4.4
and generic-4.9, and remove patches from pistachio.
So this won't be a problem when ar71xx updates linux-4.9.

Sincerely,
Weijie


2017-09-06 3:25 GMT+08:00 Christian Lamparter via Lede-dev
<lede-dev at lists.infradead.org>:
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> ---------- 已转发邮件 ----------
> From: Christian Lamparter <chunkeey at googlemail.com>
> To: Weijie Gao <hackpascal at gmail.com>
> Cc: LEDE Development List <lede-dev at lists.infradead.org>
> Bcc:
> Date: Tue, 05 Sep 2017 21:24:48 +0200
> Subject: Re: [LEDE-DEV] [PATCHv2 3/4] kernel/4.4: add generic spi-nand framework
> 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
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>



-- 
_______________________________________________
lede-devel mailing list
lede-devel at lists.infradead.org