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@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 <chunk...@googlemail.com> > To: Weijie Gao <hackpas...@gmail.com> > Cc: LEDE Development List <lede-dev@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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > -- _______________________________________________ lede-devel mailing list lede-de...@lists.infradead.org _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
