[PATCH 6/6] mtd: spi-nand: Support common SPI NAND devices

[Qi Wang 王起 (qiwang)]

On 12/03/2014 07:14 AM, Ezequiel Garcia wrote:
> 
> On 12/03/2014 06:52 AM, Qi Wang 王起 (qiwang) wrote:
> >> +
> >> +static struct nand_ecclayout ecc_layout_gd5f = {
> >> +	.eccbytes = 128,
> >> +	.eccpos = {
> >> +		128, 129, 130, 131, 132, 133, 134, 135,
> >> +		136, 137, 138, 139, 140, 141, 142, 143,
> >> +		144, 145, 146, 147, 148, 149, 150, 151,
> >> +		152, 153, 154, 155, 156, 157, 158, 159,
> >> +		160, 161, 162, 163, 164, 165, 166, 167,
> >> +		168, 169, 170, 171, 172, 173, 174, 175,
> >> +		176, 177, 178, 179, 180, 181, 182, 183,
> >> +		184, 185, 186, 187, 188, 189, 190, 191,
> >> +		192, 193, 194, 195, 196, 197, 198, 199,
> >> +		200, 201, 202, 203, 204, 205, 206, 207,
> >> +		208, 209, 210, 211, 212, 213, 214, 215,
> >> +		216, 217, 218, 219, 220, 221, 222, 223,
> >> +		224, 225, 226, 227, 228, 229, 230, 231,
> >> +		232, 233, 234, 235, 236, 237, 238, 239,
> >> +		240, 241, 242, 243, 244, 245, 246, 247,
> >> +		248, 249, 250, 251, 252, 253, 254, 255
> >> +	},
> >> +	.oobfree = { {1, 127} }
> >> +};
> >> +
> >> +static struct nand_ecclayout ecc_layout_mt29f = {
> >> +	.eccbytes = 32,
> >> +	.eccpos = {
> >> +		8, 9, 10, 11, 12, 13, 14, 15,
> >> +		24, 25, 26, 27, 28, 29, 30, 31,
> >> +		40, 41, 42, 43, 44, 45, 46, 47,
> >> +		56, 57, 58, 59, 60, 61, 62, 63,
> >> +	 },
> >> +};
> >> +
> >
> > As they are using On die ecc, oob layout definition is defined by SPI
> NAND vendors.
> > Part of oob is protected by ecc, and the rest is unprotect.
> > I am thinking if we can define a variable to indicate the range, what
> > is protect, and what is unprotect.
> 
> Yes, we should add the free out-of-band regions.

Sorry, probably I didn't explain clearly. 
I mean if we can define oob free area like this:
.oobfree_unprotect = { {1, 63} },
.oobfree_protect = { {64, 127} },
To differentiate the which OOB area is protected, which isn't protected.

> > This would be very useful for filesystem, which want to write data into
> OOB.
> >
> > For example, Jffs2 program clean marker data to oob first when format
> > operation, then will program main data into NAND flash main area when
> normal write operation.
> > That mean JFFS2 can only store clean marker into unprotect area of oob.
> 
> Yeah, but are these devices capable of writing to the OOB region only
> (without messing with the data) ?

Yes, SPI NAND have this capability. SPI NAND also have definition for NOP,
just similar with Parallel NAND, fill 0xFF to the area that don't want to 
write anything is ok.

> If I understand this correctly, supporting JFFS2 would mean implementing a
> sort of read-modify-write operation to be able to write the OOB without
> touching the main area, and viceversa.

Yes, just like this operation, but JFFS2 write OOB area first, then main area.
So JFFS2 should write data into unprotect area in OOB, then write main data,
Right? Because if write data into OOB protect area, on die ecc will generate
a ecc code and write into eccpos area. When JFFS2 write main data, a new ecc 
code will generate, and will cause conflict with old one.  

> I'd say JFFS2 is not the target filesystem for these SPI NAND devices, and
> UBI-based filesystems should be used instead (UBI don't use OOB).
> 
> > But for YAFFS2, it program main data and spare area data together into
> > NAND flash, then
> > YAFFS2 can store data into protect area of OOB.
> 
> Well, frankly, I'm not too worried about YAFFS2. It was never mainlined,
> and probably it will never be.
> 
> Do you have any reason for *not* using a UBI-based FS?

I agree with you, I just considered some legacy users customer still using JFFS2.

Thanks