From: Jonathan Larmour <jifl@jifvik.org>
To: "Jürgen Lambrecht" <J.Lambrecht@televic.com>
Cc: Ross Younger <wry@ecoscentric.com>,
Rutger Hofman <rutger@cs.vu.nl>,
eCos developers <ecos-devel@ecos.sourceware.org>,
Deroo Stijn <S.Deroo@TELEVIC.com>
Subject: Re: NAND technical review
Date: Tue, 13 Oct 2009 02:44:00 -0000 [thread overview]
Message-ID: <4AD3E92E.5020301@jifvik.org> (raw)
In-Reply-To: <4ACC61F0.3020303@televic.com>
Jürgen Lambrecht wrote:
> Ross Younger wrote:
>> - E's high-level driver interface makes it harder to add new functions
>> later, necessitating a change to that API (H2 above). R's does not; the
>> requisite logic would only need to be added to the ANC. It is not thought
>> that more than a handful such changes will ever be required, and it
>> may be
>> possible to maintain backwards compatibility. (As a case in point,
>> support
>> for hardware ECC is currently work-in-progress within eCosCentric, and
>> does
>> require such a change, but now is not the right time to discuss that.)
>
> Therefore we prefer R's model.
>
> Is it possible that R's model follows better the "general" structure of
> drivers in eCos?
> I mean: (I follow our CVS, could maybe differ from the final commit of
> Rutger to eCos)
> 1. with the low-level chip-specific code in /devs
> (devs/flash/arm/at91/[board] and devs/flash/arm/at91/nfc, and
> devs/flash/micron/nand)
> 2. with the "middleware" in /io (io/flash_nand/current/src and there
> /anc, /chip, /controller)
> 3. with the high-level code in /fs
I don't see E's model as being much different in that perspective. There
is stuff in devs/flash, io/nand and (presumably) fs as well.
The difference is more the separation out of the controller functionality
into a different layer.
> Is it correct that R's abstraction makes it possible to add partitioning
> easily?
> (because that is an interesting feature of E's implementation)
As Rutger said, it could be done - there's nothing in his design which
presents it. It's not there now though, so unless someone's working on it
it's probably not something to consider in the decision process.
Especially since it would be a big user API change.
> We also prefer R's model of course because we started with R's model and
> use it now.
You haven't done any profiling by any luck have you? Or code size
analysis? Although I haven't got into the detail of R's version yet (since
I was starting with dissecting E's), both the footprint and the cumulative
function call and indirection time overhead are concerns of mine.
>> (b) Availability of drivers
[snip]
>> - One chip: the ST Micro 0xG chip (large page, x8 and x16 present but
>> presumably only tested on the x8 chip on the BlackFin board?)
>>
>
> - Two: also the Micron MT29F2G08AACWP-ET:D 256MB 3V3 NAND FLASH (2kB
> page size, x8)
> Because if this chip, Rutger adapted the hardware ECC controller code,
> because our chip uses more bits (for details, ask Stijn or Rutger).
I'd be interested in what the issue was. From admittedly a quick look I
can't find anything about this in the code.
>> (d) Degree of testing
[snip]
> We have it very well tested, amongst others
> - an automatic (continual) nand-flash test in a clima chamber
> - stress tests: putting it full over and over again via FTP (both with
> af few big and many small files) and check the heap remaining:
> * Put 25 files with a filesize of 10.000.000 bytes on the filesystem
> * Put 2500 files with a filesize of 100.000 bytes on the filesystem
> * Put 7000 files with a filesize of 10.000 bytes on the filesystem
> Conclusion: storing smaller files needs more heap, but we still have
> plenty left with our 16MB
> * Write a bundle of files over and over again on the filesystem. We put
> everytime 1000 files of 100.000 bytes filesize on the flash drive.
> - used in the final mp3-player application
That's extremely useful to know, thanks! But a couple of further questions
on this: Did any bad blocks show up at any point? Were you using a bad
block table? Presumably there were factory-marked bad blocks on some?
Thanks,
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
next prev parent reply other threads:[~2009-10-13 2:44 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-02 15:51 Jonathan Larmour
2009-10-06 13:51 ` Ross Younger
2009-10-07 3:12 ` Jonathan Larmour
2009-10-07 16:22 ` Rutger Hofman
2009-10-08 7:15 ` Jürgen Lambrecht
2009-10-15 3:53 ` Jonathan Larmour
2009-10-15 11:54 ` Jürgen Lambrecht
2009-10-15 3:49 ` Jonathan Larmour
2009-10-15 14:36 ` Rutger Hofman
2009-10-16 1:32 ` Jonathan Larmour
2009-10-19 9:56 ` Ross Younger
2009-10-19 14:21 ` Rutger Hofman
2009-10-20 3:21 ` Jonathan Larmour
2009-10-20 12:19 ` Rutger Hofman
2009-10-21 1:45 ` Jonathan Larmour
2009-10-21 12:15 ` Rutger Hofman
2009-10-23 14:06 ` Jonathan Larmour
2009-10-23 15:25 ` Rutger Hofman
2009-10-23 18:03 ` Rutger Hofman
2009-10-27 20:02 ` Rutger Hofman
2009-11-10 7:03 ` Jonathan Larmour
2010-12-11 19:18 ` John Dallaway
2010-12-22 14:54 ` Rutger Hofman
2009-10-15 15:43 ` Rutger Hofman
[not found] ` <4ACDF868.7050706@ecoscentric.com>
2009-10-09 8:27 ` Ross Younger
2009-10-13 2:21 ` Jonathan Larmour
2009-10-13 13:35 ` Rutger Hofman
2009-10-16 4:04 ` Jonathan Larmour
2009-10-19 14:51 ` Rutger Hofman
2009-10-20 4:28 ` Jonathan Larmour
2009-10-07 9:40 ` Jürgen Lambrecht
2009-10-07 16:27 ` Rutger Hofman
2009-10-13 2:44 ` Jonathan Larmour [this message]
2009-10-13 6:35 ` Jürgen Lambrecht
2009-10-15 3:55 ` Jonathan Larmour
2009-10-13 12:59 ` Rutger Hofman
2009-10-15 4:41 ` Jonathan Larmour
2009-10-15 14:55 ` Rutger Hofman
2009-10-16 1:45 ` Jonathan Larmour
2009-10-19 10:53 ` Ross Younger
2009-10-20 1:40 ` Jonathan Larmour
2009-10-20 10:17 ` Ross Younger
2009-10-21 2:06 ` Jonathan Larmour
2009-10-22 10:05 ` Ross Younger
2009-11-10 5:15 ` Jonathan Larmour
2009-11-10 10:38 ` Ross Younger
2009-11-10 11:28 ` Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
2009-11-10 12:16 ` Chris Holgate
2009-11-12 18:32 ` NAND technical review Ross Younger
2009-10-13 14:19 ` Rutger Hofman
2009-10-13 19:58 ` Lambrecht Jürgen
2009-10-07 12:11 ` Rutger Hofman
2009-10-08 12:31 ` Ross Younger
2009-10-08 8:16 ` Jürgen Lambrecht
2009-10-12 1:13 ` Jonathan Larmour
2009-10-16 7:29 ` Simon Kallweit
2009-10-16 13:53 ` Jonathan Larmour
2009-10-19 15:02 ` 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=4AD3E92E.5020301@jifvik.org \
--to=jifl@jifvik.org \
--cc=J.Lambrecht@televic.com \
--cc=S.Deroo@TELEVIC.com \
--cc=ecos-devel@ecos.sourceware.org \
--cc=rutger@cs.vu.nl \
--cc=wry@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).