Re: NAND technical review

[Jonathan Larmour <jifl@jifvik.org>]

Rutger Hofman wrote:
> Jonathan Larmour wrote:
> 
>> Rutger Hofman wrote:
>>> 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).
>>
>> It's not just indirecting the functions, but checking what may need 
>> changing for anything which accesses the controller data, e.g. the 
>> contents of struct CYG_NAND_CTL.
> 
> OK, to answer this question, the level of detail will go up considerably.
> 
> Lots of CYG_NAND_CTL is pointers to higher layers (anc) and lower layers 
> (funs, priv, chip stuff). These would remain, although the function 
> dispatch table would be reused (or unused, I don't know about OneNAND 
> varieties). The ECC fields would remain too (if applicable, but nowadays 
> that is a CDL option) and likewise mutex. I would guess that any state 
> for the different class of controller/chip could be incorporated into priv.

Ok. And associated code updates of course.

> So, (surprisingly to me because I didn't consider anything else than raw 
> NAND), CYG_NAND_CTL seems generic enough to incorporate other types of 
> NAND chip. I'd say the controller-common API must stay -- if it doesn't, 
> I would be doubtful to fit it into a NAND harness. Reminder to self: ANC 
> must call the controller over a function dispatcher.

Although there are other ways to test code than requiring it to have an 
abstract API in order to access internals. Having the anc/controller/chip 
layers as self-contained APIs necessarily incurs some overheads.

> CYG_NAND_CHIP would need to be split into a generic part that has page 
> size, block size, num blocks, and type-specific stuff like timing and 
> like the bucket-full of ONFI parameters.

Also looking at all the source files there are quite a few parts which go 
straight to the chip layer. Again I'm not saying it can't be done, but it 
looks like it requires a lot of unpicking, and making sure the right bits 
end up in the most appropriate places.

[snip]

Thanks for the various outlines.

> I guess that this refactoring will take something like one or a few 
> days' work, including having ANC call the controller over a dispatch 
> table. I'll be glad to do it (ETA: somewhere in the next 1 to 1.5 months).

I would be very surprised by a day!

> Personal note: I am glad with this kind of detailed feedback. Still, I 
> would have preferred to get it when I put up the NAND design for 
> discussion, about a year ago.

Obviously Andrew was able to advise on some aspects at the time. But also 
at that point in time, my own understanding of the requirements of a NAND 
layer wasn't as developed as it has now become so I wouldn't have been 
able to give you that level of feedback then anyway.

Although I'm reluctant to do so, I think it would probably prove valuable 
to the decision process if I could do some size and timing measurements. 
I'll have to look at that, but as I'll need to adapt E's rwbenchmark.c to 
R, it'll take me a little time.

Finally, are there any questions about E's layer that you think I should 
ask about which I haven't?

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine