This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: NAND review

Nick Garnett wrote:
Andrew Lunn <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]