Re: NAND technical review

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

Jonathan Larmour wrote:
> Rutger Hofman wrote:
> I was referring to the "layout" field of cyg_nand_chip_id_t. Whereas spare_scatter_fill()/extract() use the spare_layout field of the cyg_nand_chip_info_t. I haven't yet found where the "layout" field of cyg_nand_chip_id_t is used. 

This represents the fourth byte of the 'regular' read_ID response. 
(First is manufacturer, second is device type, third is often 0, but may 
be defined to give further architectural details.) The specx for this 
layout byte:

bit   meaning               description
0..1  1KB, 2KB, 4KB, 8KB    page size
2     8, 16                 spare bytes per 512 data bytes
4..5  64KB, 128KB, 256KB,   block size (without spare)
6     x8, x16               bus width

The other bits differ across manufacturers.

Reading and parsing this byte is still insufficient to fully access the 
chip: its total size is unknown. It can be in the third byte, in which 
case the chip table needn't wouldn't need an entry for this chip because 
it is sufficiently self-descriptive.

>>>> 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. 
> 
> So I believe that means if you want to rewrite the boot program on 
> Blackfin _and_ use a normal layout, you wouldn't be able to use R as it 
> stands at the moment. Ack, OK.

Hot-swapping is necessary to pull this tric. It would be doable in my 
current svn version (which is coming up one of these days). It would 
imply crossing through all layers though, and it would indeed be 
horribly risky.

>> OTOH, if anything else of the NAND is going to be used, the MTD layout 
>> is required. So hot-swapping is highly desirable
> 
> Hot swapping sounds like a risky thing to do, with potentially multiple 
> subsystems wanting access to flash, not just the application.

[snip]

>>> 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.
> 
> Yes, but that isn't the same as not supporting partitions. Just that 
> they aren't fixed. They're specified on the kernel boot line, and so can 
> be configured by the user arbitrarily.... it's just that you can't 
> change them without rebooting. So I believe anyone who is using multiple 
> partitions with MTD would have difficulties interoperating with R.

If this is so (I am not conversant enough yet with Linux internals) then 
it is a very useful addition. Using multiple YAFFS devices is 
straightforward right now (I did this and met no problems).

>>> [OneNAND (and things like it) fitting into R's model]
>>>
>>>> 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.
> 
> Would that not require a significant reworking and relayering of code? 
> It seems to me that controller drivers and the chip drivers used by 
> controller drivers under this system will still want to be able to 
> access the infrastructure support for BBTs, ECCs and spare layout. From 
> what I can see, preserving that without large amounts of indirection 
> (imposing further performance and size hits) would pose quite some 
> challenge. The result would be something really quite different to what 
> R is like today.

The reworking would just be to replace the calls in the ANC of the 
controller-common API with indirect calls, and supporting this 
configurability in the CDL. OneNAND doesn't need ECC code because things 
are handled in hardware (the datasheet recommends not even checking the 
ECC status register for 2-bit failures because they are so rare). Maybe 
BBT is necessary too for OneNAND; I didn't think that through yet, but I 
would hope the BBT implementation would support different controllers 
without a lot of reworking - right now, accessing the chip already goes 
through controller calls. The indirections would be few: one for each 
top-level API call (unless the ANC must redistribute application pages 
to chip pages, which is only in case of heterogeneous chips).

In conclusion: a driver in R for a different class of chip than 'raw 
NAND' would indeed replace R's controller-common, any 
controller-device-specific, and any chip, because these are all code for 
raw NAND. I would hope that linker magic remove the code as unused from 
the binary.

A driver for OneNAND would still need to be written obviously, and it 
would share no or little code with controller-common and raw chip. My 
guess is that would hold for E too - although I don't really know 
because I have had no time to review E's code.

Rutger