Re: NAND technical review

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

Jonathan Larmour wrote:
> Rutger Hofman wrote:
>> Jonathan Larmour wrote:
>>> Rutger Hofman wrote:
>>>> Jonathan Larmour wrote:
> Ah. Your documentation includes:
> "Before the second initialization stage, some properties of the NAND 
> system can be configured. These are en/disabling of ECC generation and 
> en/disabling of a Bad Block Table (BBT). By default, ECC and BBT are 
> enabled."
> 
> I hadn't noticed that these are not in fact CDL configuration options. 
> They ought to be really.

OK. I'd say no-ECC is a property of the application/ANC and no-BBT is a 
property of a chip. I'll move these to CDL.

When I am done with this and a number of other small changes, I'll put 
up a new revision.

>>>> 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).
> 
> If it doesn't sound too silly, how were you able to test your layer on 
> the bfin then?

Well, this mode is *only* for booting a BlackFin from NAND, and for 
writing the boot blocks into NAND. For all other usage, one still uses 
the standard MTD spare layout.

>> 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'). 
> 
> You mean CYG_NAND_DRIVER_CHIP()? Presumably some way to pass a different 
> layout?
> 
> I was wondering about the extensibility of the spare layouts given how 
> much stuff is sort of hard coded - sure it may fit plenty of existing 
> chips but more can come along. In the chip ID table in io_nand_chip.c I 
> haven't worked out what the layout field is for - I can't find where it 
> is used. I also can't see how a driver in a new port can add a new chip 
> with a new layout. There's talk in read_id() of being able to do a 
> custom chip device (does that mean also you can do a custom spare 
> layout?), but it's not clear to me how a new port can add that to the 
> table since read_id() only searches the table. Obviously it's not 
> sensible to have to keep changing io/nand, and may be inappropriate for 
> custom spare layouts.

OK, a custom spare layout now is a parameter to CYG_NAND_DRIVER_CHIP(). 
The layout is used in the common controller code, see calls to function 
spare_scatter_fill() and spare_scatter_extract(). These serve ECC and 
application spare slots in the same fashion.

> NB the chip ID table can be const can't it?

Thanks, fixed.

>> 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).
> 
> That's reasonable given it's associated with the controller.

Well, not completely. The layout is only associated with the *boot 
mode*. For other use, there is no prescription of the layout, so it's 
typical to use the MTD layout - then one can share with Linux or u-boot. 
Rotten consequence: if one wants to program a new boot image into the 
first block(s) of the NAND, the boot-compatible layout must be used. 
OTOH, if anything else of the NAND is going to be used, the MTD layout 
is required. So hot-swapping is highly desirable

> But also, since R does not have partitioning, won't that potentially 
> interfere with compatibility with MTD? A Linux booted image may not be 
> using the whole chip as a single FS.

Linux has no fixed approach to partitioning, as I learned during the 
discussions on this list.

> [OneNAND (and things like it) fitting into R's model]
>> 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.
> 
> Thanks. Although of course adding more indirection may have its own 
> disadvantages.

That guarded guess was correct. OneNAND is no raw NAND chip so R's 
common controller code won't fit. The thing to do is make a driver that 
comes in place of the common controller, as suggested above. Once ANC 
supports a pluggable controller (which I will do if it makes a 
difference), adding a OneNAND will take the same amount of effort as for 
E's implementation.

Rutger