Re: NAND review

Nick Garnett wrote:
> Andrew Lunn <[email protected]> writes:
> 
>> There has been comments that Rutgers code has too many layers. Rutger
>> aims to allow as much code reuse between drivers as possible, which i
>> think is good. Simon commented that he thinks Ross's design may result
>> in a lot of code stuck in HALs where it is hard to reuse without copy
>> paste. However Ross argued that he thinks that making code reusable is
>> going to be hard, there is too many different configurations of chips
>> and controllers, etc.
>>
>> With only one supported platform on Ross's code and two with Rutgers,
>> i think it is too early to tell the truth. However, im generally in
>> favour of layers.
> 
> Just a few quick words about layering...
> 
> We have to be very careful in eCos not to over-do the abstractions.
> eCos is still an embedded operating system and not a full-featured
> general purpose OS. As such we must take care not to compromise code
> size and performance. There are some areas in eCos already where we
> have more layers than we strictly need, and performance has
> suffered. Many of the target processors are relatively slow, without
> caches or much fast memory and every extra call and indirection can
> cost a lot of cycles.

In my NAND package, there are indirect calls to the device-specific code 
of the controller. I followed the examples in the eCos documentation, 
where serial line, Ethernet etc all use this approach. Per NAND page 
that is written (typically 2KB or 4KB) there are a few indirect calls. 
My unsubstantiated intuition is that the data transfers would dominate 
performance compared to a few indirections. There are also a few 
indirect calls in the chip module, but these are used at initialization 
time only. Still, this indirection is only needed for heterogeneous 
controllers.

Besides the layering issue, there is another thing that I would like to 
point out. My NAND package has support for 3 types of NAND chip: 
small-page (the old type), 'regular' large-page (that's what you buy 
today), ONFI (I think this still has to hit the market). Small-page has 
its own instruction set, and has interrogation protocol worth 
mentioning. 'regular' and ONFI largely share the instruction set but 
differ completely in the interrogation protocol.

For a specific build, it would be not hard at all to compile only the 
support for the type of chip that is actually used, and to /not/ compile 
command implementations and interrogation for the other types.

This same observation would hold for the ECC routines, and, as I 
mentioned in an earlier email, for the code that hides away controller 
or chip heterogeneity.

Rutger