From: Rutger Hofman <rutger@cs.vu.nl>
To: Nick Garnett <nickg@ecoscentric.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
john@dallaway.org.uk,
"ecos-devel@ecos.sourceware.org"
<ecos-devel@ecos.sourceware.org>
Subject: Re: NAND review
Date: Thu, 11 Jun 2009 11:25:00 -0000 [thread overview]
Message-ID: <4A30EA39.8030008@cs.vu.nl> (raw)
In-Reply-To: <m3eitsm1is.fsf@xl5.calivar.com>
Nick Garnett wrote:
> Andrew Lunn <andrew@lunn.ch> 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
next prev parent reply other threads:[~2009-06-11 11:25 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-19 8:27 Simon Kallweit
2009-05-19 13:47 ` Ross Younger
2009-05-19 14:17 ` Andrew Lunn
2009-05-20 13:24 ` Bart Veer
2009-05-20 13:34 ` Rutger Hofman
2009-05-20 13:53 ` Andrew Lunn
2009-05-20 13:56 ` Gary Thomas
2009-05-20 14:22 ` Andrew Lunn
2009-05-20 15:22 ` Andrew Lunn
2009-05-20 15:34 ` Bart Veer
2009-05-20 13:58 ` Rutger Hofman
2009-05-20 14:16 ` Ross Younger
2009-05-20 14:21 ` Gary Thomas
2009-05-20 15:25 ` Ross Younger
2009-05-20 15:37 ` Gary Thomas
2009-05-19 16:29 ` Andrew Lunn
2009-06-03 8:51 ` Andrew Lunn
2009-06-03 10:21 ` Ross Younger
2009-06-03 10:48 ` Andrew Lunn
2009-06-03 11:52 ` Simon Kallweit
2009-06-03 12:26 ` Rutger Hofman
2009-06-03 13:33 ` Jürgen Lambrecht
2009-06-10 17:39 ` Nick Garnett
2009-06-11 11:25 ` Rutger Hofman [this message]
2009-06-13 16:31 ` Andrew Lunn
2009-06-18 14:10 ` Nick Garnett
2009-06-19 7:47 ` Andrew Lunn
2009-06-19 14:14 ` Ross Younger
2009-06-19 15:02 ` Andrew Lunn
2009-06-19 16:54 ` Jürgen Lambrecht
2009-06-29 11:09 ` Nick Garnett
2009-06-19 8:07 ` Andrew Lunn
2009-06-19 11:37 ` Daniel Morris
2009-06-19 12:06 ` Andrew Lunn
2009-05-20 1:02 ` Jonathan Larmour
2009-05-20 7:11 ` Simon Kallweit
2009-05-20 11:12 ` Rutger Hofman
2009-05-20 11:29 ` Simon Kallweit
2009-05-20 13:37 ` Rutger Hofman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A30EA39.8030008@cs.vu.nl \
--to=rutger@cs.vu.nl \
--cc=andrew@lunn.ch \
--cc=ecos-devel@ecos.sourceware.org \
--cc=john@dallaway.org.uk \
--cc=nickg@ecoscentric.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).