Re: nand oob layout assumptions

[David Updegraff <dave@cray.com>]

In all this discussion, the need for anyone outside the driver to know
hardware positions of ECC and badblock markers still elludes me.  Yes, 
various FS need to scribble oob info of their own in a particular 
format, and in a way that won't scribble over ecc/badblock, but is there 
anything more than that?

So, again, what if the 'oobsize' and 'oob_buf' (or a renamed relative 
thereof) were interpreted to mean "region available in OOB for misc. 
file system housekeeping, that will not stomp on private ECC or badblock 
areas and will not be interpreted by nand driver".  And let the driver 
put it wherever it wants/needs to in OOB.  Driver gets to ignorant of FS 
details, FS gets to be ignorant of chip-HW-dependent ECC and badblock 
layout.

>>What else would you need ? 
> 
> 
> Nothing more, but it does live where it is in the hardware driver.
> 
> 
>>I'm not happy to build in the bad block bitmap stuff as a general solution. 
>>Next will be translation tables, bad block remapping and all kind of crap, 
>>which is not neccecary to run a NAND FLASH aware filesystem. 
> 
> 
> We don't need to build it in as a general solution -- the DiskOnChip
> code will do it itself. All we need to do is keep the API sufficiently
> versatile that the FS doesn't need to know about the peculiarities of
> the DiskOnChip -- it just gets told which bytes of the OOB area it can
> use, and does so.
> 
> The DiskOnChip uses the first 6 bytes of the OOB area for hardware ECC,
> and bad block information is elsewhere on the medium.
> 
> 
>>The NAND specs have defined to have the bad block markers in the OOB area, 
>>which is quite clever, as it does not restrict the usage of any byte in the 
>>main area.
> 
> 
> No, the NAND specs have defined the bad block markers to be in the OOB
> area when the device is shipped. What you do with it after that is up to
> you. And in the case of the DiskOnChip that means the bad block
> information is moved. We _really_ want to honour that and keep it within
> the hardware driver. I don't want any possibility of erasing bad blocks,
> and I'm not overly happy with thinking non-bad blocks are bad just
> because the device has already been used with NFTL and has ECC data in
> byte 5.
> 
> 
>>Nand.c needs bad block handling in the sense of preventing erase of bad 
>>blocks. Maybe the prevention of reading / writing bad blocks too. And the 
>>possibility to have a bad block detection function, which covers specific 
>>cases like DOC.
>>
>>But this does not change the interface. 
> 
> 
> Except that in the file system we need to call the device's
> ->is_bad_block() function rather than poking at the OOB area.
>  
> 
>>ECC positions are a totaly different thing. If we want to have a fixed scheme 
>>for storing ECC bytes, which is not neccecary even with hardware ECC, as the 
>>hardware ECC only does the ECC calculation and no placing of ECC data into 
>>OOB, 
> 
> 
> On the DiskOnChip I think it has to be the first six bytes of the OOB.
> You read <data + ECC> and check a _bit_ to see if there was an error.
> You don't read the ECC syndrome and compare with what you separately
> read from the medium.
> 
> 
>>then we have to use _ONE_ final ECC placement scheme for all filesystems 
>>and therefor we can only use the SmartmediaCard layout, as doing not so would 
>>prevent the development of a SmartMedia FAT fs driver. This would break YAFFS 
>>support complete. JFFS2 uses the SmartMedia layout anyway.
> 
> 
> We don't need a fixed ECC scheme. But we do need to tell the file system
> what we support. Those should include the SmartMedia software ECC, and
> may include the DiskOnChip hardware ECC too. 
> 
> JFFS2 uses the DiskOnChip ECC on DiskOnChip already, doesn't it?
> 
> 
>>>Other than noticing them and avoiding them, there really isn't much
>>>handling to be done.
>>
>>True, but it still is a job of the filesystem and therefor it must have access 
>>to this information.
> 
> 
> Yes. It _absolutely_ needs access to the information 'is this a bad
> block?'. What it doesn't need is stuff like "what byte in the OOB area
> would tell us if this was a bad block".
>