Re: NAND technical review

[Rutger Hofman <rutger@cs.vu.nl>]

Jonathan Larmour wrote:
> [ Sorry for getting back to this late - I wanted to continue with Ross 
> before he went on holiday ]
> 
> Rutger Hofman wrote:
>> Jonathan Larmour wrote:
>>> Does your implementation _require_ a BBT in its current 
>>> implementation? For simpler NAND usage, it may be overkill e.g. an 
>>> application where the number of rewrites is very small, so the 
>>> factory bad markers may be considered sufficient.

I had forgotten: there is a configuration option to bypass BBT and only 
use factory-bad markers (and caveat emptor).

>> This is a bit hairy in my opinion, and one reason is that there is no 
>> Standard Layout for the spare areas. One case where a BBT is forced: 
>> my BlackFin NFC can be used to boot from NAND, but it enforces a spare 
>> layout that is incompatible with MTD or anybody. It is even 
>> incompatible with most chips' specification that the first byte of 
>> spare in the first page of the block is the Bad Block Marker. 
>> BlackFin's boot layout uses this first byte in a way that suits it, 
>> and it may be 0 -- which would otherwise mean Bad Block.
> 
> I infer that your layer can cope with that? I didn't see the handling 
> for that in io_nand_chip_bad_block.c.

No (not yet). To use the NAND controller in this way, a different spare 
layout must be used for the chip. Although there are no obstacles to 
selecting different spare layouts, there is no support for that yet. It 
would require one extra parameter in the chip device struct 
'constructor' (e.g. with NULL for 'choose default = MTD compatible'). 
For the record: MDT/Blackfin/u-boot has support for this different 
layout, but it is build-static. MDT cannot hot-swap layouts (at the moment).

> Is your BBT compatible with Linux MTD? Including your use of a mirror?

Yes, I read MTD, and tried to copy their BBT handling as faithfully as 
possible without actually copying code. It is on my stack to check if 
the BBTs are indeed identical; as you may have noticed elsethread, my 
eCos application wants to share a YAFFS 'disk' with u-boot which has MTD.

>>>> (b) Dynamic memory allocation
>>>>
>>>> R's layer mandates the provision of malloc and free, or compatible
>>>> functions. These must be provided to the cyg_nand_init() call.
>>>
>>>
>>> That's unfortunate - that limits its use in smaller boot loaders - a 
>>> key application.
>>
>>
>> Well, it is certainly possible to calculate statically how much space 
>> R's NAND layer is going to use, to allocate that statically, and write 
>> a tiny function to hand it out piecemeal at the NAND layer's request. 
> 
> If you know what it's going to be (at most), it could just be allocated 
> statically and just used directly surely? That's got the lowest overheads.
> 
> E's implementation had a good idea of a CDL variable for the maximum 
> supported block size. Then individual HALs or driver packages can use a 
> CDL 'requires' to ensure it's >= the block size of the chips really in use.

I can follow Ross's example here. Together with a switch to constructor 
and a cleanup of printfs, that will take some days. If it matters in the 
decision, I will schedule this to be finished within one month.

>> Still, another possible implementation for this page buffer would be 
>> on the stack (not!), or in the controller struct. That would grow then 
>> by 8KB + spare.
> 
> Or a single one for all chips maybe (since chances of clashes seem 
> pretty small, so just protected with a mutex). And only if the program 
> verify option is enabled of course. As per above, the page buffer size 
> could be derived from the configuration, with appropriate CDL.

Right, I'll do that when the allocator dependency goes.

>> See my comment above. The datasheet on e.g. KFM{2,4}G16Q2A says: 
>> "MuxOneNAND™‚ is a monolithic integrated circuit with a NAND Flash 
>> array using a NOR Flash interface."
> 
> OneNAND isn't like SSD or MMC which essentially provide a block 
> interface and an advanced controller hiding the details of NAND. It 
> isn't like NOR flash because you can't address the entire array - as 
> shown by the fact it only has a 16-bit address bus. Instead with OneNAND 
> you get an SRAM buffer as a "window" into the NAND array. There are 
> commands to load data from NAND pages into the SRAM buffers, or write 
> them back. It has onboard ECC logic, but it has a very different way of 
> controlling the NAND. You do get access to both data and spare areas too.
> 
> You can consider this the sort of thing I mean when I say that 
> manufacturers can come up with interesting things which break rigid 
> assumptions of how you talk to NAND chips. So my concern is not (just) 
> that your layer can't support OneNAND, but it couldn't support anything 
> which also had a different interface.

> Obviously you already support small versus large page, which require 
> different protocols, but they are still relatively similar in how 
> they're controlled. Would it even be possible to sensibly extend your 
> generic layer to support something like OneNAND? Without having a large 
> number of kludges?

I will take a better look at the OneNAND datasheet. You are right, it is 
software-wise as different from NOR as from 'raw' NAND. My guarded guess 
now is that integration into R would imply a replacement of the Common 
Controller code (by configuration or by 'object-oriented' indirect calls 
over a device struct). I will report on this later.

> Ross said that the Samsung K9 is pretty similar to ONFI, other than how 
> you read the device ID etc. Is your layer equally close?

Yes, absolutely. The reason is that the large-page chip that I tested is 
a 'regular' large-page chip, same as Samsung K9, and same as Jurgen 
Lambrecht's chip. All 'regular' large-page chips are equally pretty 
similar to ONFI. Small-page chips are not in ONFI though.

Rutger